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ABSTRACT 


Restricted  water  transits  by  U.  S.  Navy  ships  require  detailed  planning  by 
Commanding  Officers,  Navigators  and  the  entire  ship  control  watch  team.  The  methodical 
maritime  navigation  planning  process  currently  used  has  not  changed  appreciably  since 
World  War  Two.  The  process  remains  a  manual  one,  relying  primarily  on  hard  copy  data 
(which  is  distributed  via  the  U.  S.  Postal  system  or  other  Governmental  shipping  means) 
for  updates  to  the  navigation  picture.  The  explosion  of  information  sources  and 
technology  provides  an  opportunity  to  revolutionize  the  entire  maritime  navigation 
planning  process. 

The  thesis  contains  an  overview  of  the  current  manual  navigation  planning  process 
used  by  the  U.S.  Navy.  Alternatives  for  migrating  the  current  method  to  an  automated 
process  are  explored.  A  requirements  analysis  is  conducted  to  capture  fleet  navigator 
feedback  for  a  prototype  automated  navigation  planning  tool. 

Conclusions  drawn  from  this  study  are  implemented  in  the  prototype  on-Une 
navigation  planning  tool  that  has  been  dubbed  “GatorNet.”  Additionally,  a  requirements 
document  is  developed  with  the  objective  of  shifting  the  maritime  navigation  planning  and 
debriefing  paradigm  from  a  manual  mindset  to  an  automated  one. 
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INTRODUCTION 


A.  CURRENT  FLEET  NAVIGATION  PLANNING  AND  SHORTFALLS 

Restricted  water  transits  by  naval  ships  require  detailed  planning  by  Commanding 
OfiBcers,  Navigators  and  the  entire  ship  control  watch  team.  Standardized  navigation 
planning  guidelines  have  been  developed  to  improve  safety  and  an  extensive  publication 
system  provides  the  vast  majority  of  information  used  in  the  planning  process.  Typically 
this  information  is  dated  and  does  not  incorporate  organized  port  visit  and  harbor  transit 
feedback  from  the  fleet.  The  planning  process  has  evolved  over  many  years,  but  the 
planning  tools  have  changed  very  little.  The  explosion  of  information  sources  and 
technology  provide  an  opportunity  to  revolutionize  the  entire  navigation  planning  process. 

Great  strides  have  been  made  in  providing  imagery  intelligence  through  the  Joint 
Deployable  Information  Sub-System  (JDISS).  Battle  space  awareness  has  been  greatly 
improved  using  the  Joint  Maritime  Command  Information  System  (JMCIS)  by  fusing 
multiple  C4I  systems  into  a  single  tactical  display.  The  Global  Command  and  Control 
System  (GCCS)  has  evolved  and  taken  the  fusion  concept  of  JMCIS  one  step  further, 
incorporating  a  UNIX  based  client  server  system  of  standardized  relational  databases. 
However,  due  to  the  low  profile  nature  of  “routine”  navigation  planning,  a  lesser  effort 
has  been  made  to  use  information  technology  to  significantly  improve  this  process. 

The  shift  in  focus  from  blue  water  to  littoral  operations  has  increased  near  shore 
navigation  operations.  Ironically,  this  seemingly  “routine”  process  provides  one  of  the 
greatest  safety  risks  during  peacetime  operations.  During  wartime  operations  when 
mining  and  near-shore  hostile  actions  require  even  more  precise  navigation,  there  will  be 
an  exponential  increase  in  the  amount  of  required  navigation  planning 

Naval  ships  safely  transit  dozens  of  harbors  every  day.  Navigators  plan  and  brief 
the  transit  using  a  library  of  hard  copy  publications  designed  to  provide  critical  safety 
information.  Occasionally,  record  messages  written  by  ships  that  have  “recently”  made  the 
transit  lend  valuable  insight.  Often  the  Commanding  Officer  and  Navigator  have  no  choice 
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but  to  rely  heavily  on  the  judgment  of  a  paid  pilot  (who  sometimes  speaks  broken  English) 
to  safely  navigate  foreign  harbors.  Quartermasters  take  visual  bearings  off  radio  towers, 
lights,  and  water  tanks  believed  to  be  the  proper  navigation  aid.  Visual  fixes  are 
compared  with  Global  Positioning  System  (GPS)  measurements  as  the  ship  transits  the 
harbor.  As  the  ship  approaches  the  dock,  the  Commanding  Officer  gets  his  first  view  of 
the  pier,  tugs  and  fittings.  After  a  ship  moors,  all  this  information  is  debriefed  in  a  matter 
of  minutes  and  rarely,  if  ever,  is  any  of  this  valuable  information  captured  and  passed  on  to 
the  next  ship  that  must  make  the  transit.  An  objective  of  this  thesis  is  to  shift  the 
navigation  planning  and  debriefing  paradigm  from  a  manual  mindset  to  an  automated  one. 

Just  as  with  U.  S.  Navy  Food  Service,  the  surface  navigation  planning  process  has 
not  changed  appreciably  since  World  War  Two  [Ref  1].  The  process  remains  a  manual 
one,  relying  primarily  on  hard  copy  data  (which  is  distributed  via  the  U.  S.  Postal  system 
or  other  Governmental  shipping  means)  for  updates  to  the  navigation  picture.  The 
explosion  of  information  sources  and  technology  has  gone  relatively  unnoticed  as  viewed 
from  the  eyes  of  today’s  U.  S.  Navy  navigation  planners.  Distributing  a  relational 
database  on  CD-ROM  and  using  the  World  Wide  Web  as  a  vehicle  to  rapidly  provide  up- 
to-date  digital  navigation  planning  information  to  fleet  users  shows  great  promise,  and  is 
supported  by  the  fleet  navigation  planners  (see  Chapter  II). 

B.  FLEET  NAVIGATION  GUIDANCE  AND  INITIATIVES 

1.  Navigation  Guidance  Provided  by  the  Commanders,  Naval  Surface 
Forces,  Naval  Air  Forces  Atlantic  and  Pacific 

Standardized  navigation  planning  guidelines  have  been  developed  to  improve 
safety.  In  addition  to  the  extensive  publication  system,  the  Commanders,  Naval  Surface 
Forces  and  Naval  Air  Forces,  U.  S.  Pacific  and  Atlantic  Fleets  (CNSL/CNSPINST 
3530.4)  Instruction  provides  the  vast  majority  of  guidance  used  in  the  planning  process. 
Appendix  A.  is  a  comprehensive  list  of  all  navigation  planning  publications  and  products  in 
use  in  the  fleet  today. 
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The  T5^e  Commander’s  navigation  guidance  primarily  focuses  on:  (a)  The  flow  of 
navigation  information  from  the  Navigation  Watch  Team  to  users,  (b)  Maintaining 
proficiency  in  navigation  skills,  and  (c)  Emphasizing  navigation  precision,  accuracy  and 
responsibility. 

Although  there  is  an  acknowledgment  in  the  Type  Commander’s  Instruction  of  the 
increasing  complexity  of  ship  operations,  there  is  little  guidance  for  applying  information 
technology  to  help  with  navigation  planning,  other  than  a  suggestion  to  Navigators  to  use 
the  National  Imagery  and  Mapping  Agency  (NDVLA)  Navigation  Information  Network 
(NAVINFONET).  In  short,  the  focus  of  the  entire  instruction  is  on  management  of  the 
manual  navigation  process  [Ref  2], 

2.  Navigation  Sensor  System  Interface  (NAVSSI) 

The  Navigation  Sensor  System  Interface  (NAVSSI,  AN/SSN-6)  was  installed  and 
tested  on  USS  YORKTOWN  (CG-48)  as  a  part  of  the  Smart  Ship  Program.  NAVSSI 
was  established  to  fulfill  Chief  of  Naval  Operations  (CNO)  requirements  to  use  and 
distribute  GPS  data  as  the  primary  source  of  navigation  data  [Ref  2].  NAVSSI  contains 
the  following  functionality; 

•  Provides  an  accurate  and  automated  distribution  of  navigation  data  to  the 
shipboard  users. 

•  Allows  the  ship’s  Navigator  and  bridge  crew  to  perform  mission  planning, 
underway  voyage  progress  tracking,  and  formation  steaming  functions  using 
Government  Off-the  Shelf  (GOTS)  software. 

•  Distributes  real-time,  best  available  navigation  data. 

•  Provides  data  for  use  by  strike  warfare  systems  for  GPS  initialization. 

•  Places  control  of  navigation  selection  and  distribution  in  the  hands  of  the 
navigation  team. 

•  Provides  the  navigation  team  with  a  workstation  for  Battle  Group  navigation 
planning  and  monitoring. 
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•  Provides  a  system  to  support  safe  navigation  using  digital  nautical  charts  and 
chart  tools,  to  meet  Electronic  Chart  Distribution  Information  System  (ECDIS) 
functionality.  NAVSSI  is  beginning  to  be  installed  aboard  fleet  ships,  and  also 
has  been  introduced  into  navigation  training  at  the  Fleet  Training  Centers 
Atlantic  and  Pacific. 

3.  NAVINFONET,  NAVCEN,  and  MARBLOG 

There  are  several  U.  S.  Government  and  commercial  tools  and  World  Wide  Web 
Sites  that  have  been  created  to  aid  in  Navigation  Planning.  NIMA  maintains  an  American 
Standard  Code  for  Information  Interchange  (ASCII)  based  bulletin  board  system  called 
the  NavInfoNet,  or  Navigation  Information  Network,  to  help  provide  timely  navigation 
safety  information  to  military  and  civihan  mariners.  By  dialing  up  a  9600  baud  phone  line 
at  NIMA,  a  user  can  obtain  information  such  as  Chart  Corrections,  Broadcast  Warnings, 
Maritime  Administration  Advisories,  List  of  Lights,  Anti-shipping  activity  messages,  and 
U.  S.  Coast  Guard  Light  Lists:  Although  there  is  no  charge  for  the  use  of  the  system, 
there  are  long-distance  telephone  charges  involved,  and  this  can  be  cost-prohibitive  for  the 
ship  at  sea  using  the  expensive  International  Maritime  Satellite  (INMARSAT)  single 
channel  telephone  system.  Some  ships  have  reported  that  they  are  not  allotted  enough 
phone  lines  to  permit  use  of  a  single  line  for  NavInfoNet.  NIMA  recognizes  the  shortfalls 
of  this  ASCII  based  system,  and  is  currently  upgrading  it  into  a  graphics  based  World 
Wide  Web  site,  scheduled  for  implementation  in  October  1998  [Ref  3]. 

There  are  other  sources  of  navigation  information  that  are  available  now  on  the 
World  Wide  Web,  such  as  the  Coast  Guard’s  Navigation  Center  web  site  called  NAVCEN 
[Ref  4].  Some  of  the  useful  navigation  information  available  at  this  site  includes  Local 
Notices  to  Mariners  and  navigation  communications  advisories  for  LORAN-C  (Long- 
Range  Navigation)  and  GPS.  In  addition,  there  are  numerous  other  non-government 
navigation  and  marine  safety  web  sites,  such  as  the  Institute  of  Navigation  [Ref  5]  and 
MARDLOG  [Ref  6]  sites,  which  contain  information  such  as  safety  advisories  and 
advertisements  on  commercial  navigation  products. 
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4.  The  Computerized  American  Practical  Navigator  (Cap’n) 

The  Computerized  American  Practical  Navigator  (Cap’n)  is  a  commercial  software 
navigation  tool  widely  used  on  Naval  Ships.  Its  functionality  is  broad,  and  navigators  can 
use  it  to  manage  daily  navigation  chores  including  voyage  planning  and  navigating  with 
computer  display  electronic  charts  via  GPS  or  celestial  inputs  [Ref.  7].  Numerous  other 
useful  functions  include  tide  and  current  predictions,  set  and  drift  calculation  and 
automatic  dead  reckoning.  Also,  several  large  databases  can  be  accessed  through  the  tool 
including  Aids  to  Navigation,  NIMA  and  NOAA  charts,  undersea  features  and  ports. 
Nautical  Technologies,  Ltd.  distributed  a  demonstration  version  of  this  commercial 
software  package  to  the  fleet  in  1994,  and  several  hundred  U.S.  fleet  ships  have  reported 
that  they  are  using  the  program  (see  Chapter  II). 

Although  the  usefulness  of  the  Cap’n  program  is  obvious,  it  has  yet  to  be  officially 
sanctioned  and  distributed  by  the  U.  S.  Navy.  In  fact,  NAVSSI  is  the  Navy’s  answer  for 
electronic  charting.  One  weakness  of  the  Cap’n  system  is  that  it  was  designed  to  operate 
in  a  stand-alone  mode,  and  not  to  be  interfaced  with  the  World  Wide  Web.  Although  it  is 
a  powerful  tool  and  it  continues  to  be  improved,  it  is  still  not  a  single  source  system 
tailored  for  all  of  the  Navy’s  navigation  planning  needs. 

C.  RELEVANT  FLEET  C4I  INITIATIVES 

There  are  numerous  Command,  Control,  Computer,  Communication  and 
Intelligence  (C4I)  initiatives  underway  by  several  federal  agencies  that  to  some  extent  or 
another  are  merging  navigation  with  information  technology.  Many  of  these  initiatives 
focus  on  using  digitized  nautical  charts,  improving  navigation  accuracy  through  use  of 
Differential  GPS  (DGPS)  or  the  Ring  Laser  Gyro  Navigator  (RLGN)  inertial  navigation 
system,  and  integrating  these  technologies  into  an  information  suite  on  the  ship’s  bridge. 
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Some  of  the  leading  Department  of  Defense  C4I  initiatives  include: 


1.  GCCS 

The  Global  Command  and  Control  System  (GCCS)  is  a  “system  of  systems”  which 
has  replaced  the  Worldwide  Military  Command  and  Control  System  (WWMCCS)  as  the 
U.  S.  Joint  command  and  control  system.  There  are  several  GCCS  applications  that  have 
tremendous  relevance  to  the  management  of  the  surface  navigation  problem.  Logistical 
information  contained  in  key  port  databases,  for  example,  permits  planners  to  determine 
well  in  advance  if  a  particular  port  can  support  a  ship  visit.  These  GCCS  applications 
include; 


a)  Airfields  Databases  via  JOPES  and  DAFIF 

A  Joint  Operation  Planning  and  Execution  System  (JOPES)  application  on 
airfields  exists  and  is  interfaced  with  GCCS.  However,  it  is  extremely  difficult  for  a  fleet 
user  to  access  this  database,  as  the  application  is  only  licensed  by  the  Defense  Information 
Systems  Agency  (DISA,  the  GCCS  program  manager)  to  ten  Commander  in  Chief 
(CINC)  level  commands.  NIMA  also  maintains  the  Digital  Aeronautical  Flight 
Information  File  (DAFIF).  This  database  contains  airport,  runway,  navigation  aid,  enroute 
and  terminal  data  [  1 9] . 

b)  Ports  Database  via  GSORTS 

A  Ports  Database  is  available  via  the  GCCS  Status  of  Operational 
Readiness  and  Training  Systems  (GSORTS),  and  contains  some  useful  information  on 
potential  ports  of  call.  This  information  is  similar  to  that  available  in  the  government’s 
Publication  150,  the  World  Ports  Index. 

c)  Overlay  management  via  COMPASS  Middleware 

The  Common  Operational  Modeling,  Planning  and  Simulation  Strategy 
(COMPASS)  is  an  application  of  services  interfaced  with  GCCS.  This  system  permits 
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staff  planners  to  model  and  simulate  plans  in  a  real-time,  collaborative  manner.  Scenarios 
ranging  from  chemical  warfare  to  amphibious  assault  can  be  tested  to  build  insight  into 
exercises  and  actual  combat  operations  [Ref.  8].  The  system  was  designed  to  use  real- 
world  data  to  help  planners  evaluate  the  key  decisions  of  an  operation.  COMPASS  also 
contains  some  functionality  that  is  useful  for  navigation  planning,  such  as  chart  and  map 
overlay  capabilities. 

d)  SIPRNET  andNIPRNET 

The  Secret  Internet  Protocol  Router  Network  (SIPRNET)  is  the  secret- 
level  packet  data  portion  of  the  Defense  Information  Systems  Network.  The  backbone  of 
SIPRNET  is  a  DOD  Wide  Area  Network  (WAN)  composed  of  an  autonomous  network 
of  new  hardware  and  software.  SIPRNET  is  integrated  with  GCCS  and  allows  users  to 
transmit  and  receive  classified  data  up  to  the  Secret/Nofom  level  from  a  variety  of 
subsystems  and  applications  [Ref  9:pp.  7-78].  Concurrently,  the  unclassified  but  sensitive 
Internet  Protocol  Router  Network  (NIPRNET)  uses  commercial  protocols  to  transport 
unclassified  data  over  the  Defense  Information  Systems  Network.  Both  the  SIPRNET 
and  NIPRNET  have  been  installed  and  are  in  worldwide  use.  These  trusted  conduits 
provide  more  than  adequate  potential  for  growth,  and  might  include  a  prototype 
navigation  planning  Web  site. 

2.  Lessons  Learned  Database 

The  U.  S.  Navy  maintains  an  extensive  database  of  ship,  submarine,  and  squadron 
lessons  learned  via  the  Navy  Lessons  Learned  DataBase  (NLLDB).  Fleet  personnel 
created  this  library  of  corporate  knowledge  with  message  input  using  the  Navy 
Instructional  Input  Program  (NIIP)  [Ref  10],  The  entire  database  is  distributed  quarterly 
by  the  Director,  Navy  Tactical  Support  Activity,  in  the  form  of  CD-ROMs.  This  digitized 
information  is  a  part  of  the  Navy  Tactical  Information  Compendium  (NTIC)  series  “A.”  A 
more  thorough  discussion  of  this  system  is  contained  in  Chapter  II,  Section  B. 
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3.  Internet  to  Sea  (SEANET)  Program 

The  SeaNet  Project  is  a  collaborative  effort  to  bring  the  Internet  to  all  fleet  ships. 
The  program  was  originated  as  an  academic  study  at  the  Naval  Postgraduate  School  in 
Monterey,  California.  There  are  many  dimensions  to  the  project,  including  global 
connectivity  via  future  Low  Earth  Orbit  satellite  networks.  The  basic  concept  of 
widespread  Internet  access  to  ships  at  sea  with  healthy  bandwidth  resources  is  a 
cornerstone  of  the  project  [Ref  11].  The  concept  of  using  commercially  available 
communications  and  protocols  can  also  be  applied  to  a  prototype  navigation  Web  Site. 

4.  Gobal  Broadcast  Service 

The  Global  Broadcast  Service  (GBS)  is  a  DOD  application  of  commercially 
developed  technology.  The  service  consists  of  a  network  of  high-powered  satellites  and 
small  receive  terminals.  When  the  service  is  established  in  the  near  future,  an  exponential 
increase  over  current  Satellite  Communication  (SATCOM)  capability  and  bandwidth  will 
result,  due  to  the  use  of  smaller  antennas  and  higher  data  rates  [Ref  12].  In  short,  this 
initiative  is  undergoing  initial  operational  testing,  and  appears  to  be  a  promising  means  of 
increasing  available  bandwidth  to  fleet  users. 

5.  Information  Technology  for  the  21*‘  Century  (IT-21) 

Information  Technology  for  the  21st  Century  (IT-21)  is  a  Fleet  Commander  in 

Chief  initiative  to  push  all  administrative  and  tactical  computing  business  to  desktop 

personal  computers.  The  following  excerpts  from  the  Commander  In  Chief,  U.  S.  Pacific 

Fleet’s  vision,  summarize  the  concept: 

A  shift  from  platform  centric  warfare  to  network  centric  warfare; 
....principal  elements  of  IT-21  are  afloat  LANs  and  ashore  LANAVANs 
populated  by  'state-of-the-shelf  personal  computers  which  will  integrate 
tactical  and  tactical  support  applications  with  connections  to  enhanced 
satellite  systems  and  ashore  networks.  Furthermore,  IT-21  is  a 
philosophical  C4ISR  warfighting  process  transformation  away  from 
expensive,  single-function  workstations  to  affordable,  highly  capable 
personal  computers. 
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In  short,  the  IT-21  plan  envisions  that  all  naval  computer  business,  both  tactical 
and  non-tactical,  will  be  driven  to  a  single,  networked,  desktop  computer  [Ref,  13],  This 
movement  has  generated  widespread  support  throughout  the  Navy,  including  the  support 
of  the  Department  of  the  Navy  Chief  Information  Officer  (DON  CIO).  One  of  the  largest 
benefits  this  movement  will  bring  to  fleet  navigators  is  a  significant  increase  in  the  numbers 
of  networked  microcomputers  available  for  both  World  Wide  Web  access  and  navigation 
planning. 

D.  A  NEW  TARGET  ARCHITECTURE 

Key  to  a  new  target  navigation  planning  architecture’s  success  is  accessibility  by 
the  navigation  watch  team  and  user  fiiendliness.  If  the  entire  planning  concept  and 
feedback  process  becomes  too  difficult,  the  system  will  fail.  A  working  solution  to  the 
manual  navigation-planning  problem  is  proposed  in  the  form  of  a  prototype  Web  Site. 
The  tool  has  been  developed  and  a  Web  site  was  used  so  that  the  fleet  can  immediately 
appreciate  it.  The  current  planning  process  has  been  thoroughly  researched  and  detailed 
requirements  fi’om  the  fleet  have  been  incorporated  into  GatorNet,  the  Navigator’s 
Planning  Network. 

E.  SUMMARY  OF  REMAINING  CHAPTERS 

Chapter  II  describes  the  methodology  used  to  design  and  disseminate  a  navigation 
survey  to  the  fleet.  The  chapter  presents  data  collected  and  analyzes  user  requirements 
and  how  they  relate  to  ongoing  initiatives.  Alternative  hardware  platforms  and 
technologies  for  a  navigation  planning  system  are  explored  in  Chapter  III.  A  discussion  of 
automating  traditionally  manual  navigation  tasks  is  included.  An  overview  of  the 
GatorNet  rapid  prototype,  a  World  Wide  Web  based  navigation  planning  tool,  is  presented 
in  Chapter  IV.  Functionality  of  the  tool  is  discussed  and  design  considerations  are 
included.  Software  tools  used  to  create  the  graphical  user  interface  are  explained  in  detail. 
A  discussion  of  issues  in  implementing  and  integrating  the  prototype  into  the  fleet  is 
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presented  in  Chapter  V.  Finally,  recommendations  for  further  research  and  lessons  learned 
are  presented  in  Chapter  VI. 
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n.  REQUIREMENTS  ANALYSIS 


A.  FLEET  SURVEY  DESIGN 

1.  Methodology 

To  better  understand  the  fleet’s  requirements  for  navigation  planning,  the  survey  in 
Appendix  B  was  distributed  throughout  the  fleet.  Due  to  the  widely  dispersed  population, 
a  survey  was  deemed  the  only  feasible  tool  for  data  collection.  It  was  used  as  an 
exploratory  study  to  gauge  overall  opinion  before  giving  the  working  prototype  any 
specific  direction.  The  total  population  of  ships  and  staffs  was  known  to  be  less  than  five 
hundred.  Some  of  the  groups  that  would  be  analyzed  had  a  smaller  population  (i.e.  12 
CV/CVNs,  27  CG/CGNs,  24  mine  warfare  ships).  Anticipating  a  return  rate  less  than 
50%,  it  was  necessary  to  survey  the  entire  population  to  maintain  statistical  significance 
when  looking  at  those  smaller  groups.  Since  the  survey  was  also  meant  to  obtain  new 
ideas,  a  population-wide  survey  was  appropriate. 

In  order  to  increase  the  return  rate,  a  cover  letter  was  included  and  the  surveys 
were  sent  directly  to  the  Commanding  Officer.  The  desired  respondent  was  the  ship’s 
Navigator  or  staff’s  Navigation  Plans  Officer.  It  was  requested  that  commands  reproduce 
copies  locally  to  obtain  opinions  of  the  Operations  Officer,  leading  enlisted  Quartermasters 
(QMs),  and  leading  enlisted  Operations  Specialists  (OSs).  To  encourage  feedback  yet 
allow  group  comparison,  the  survey  maintained  anonymity  and  collected  the  following 
demographics: 

•  Rank 

•  Title/Job  Position 

•  Time  in  Billet 

•  Command 

•  Command  Status  (ashore,  deployment,  work-ups,  etc.) 
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To  encourage  further  feedback,  the  survey  was  kept  to  the  front  and  back  of  a 
single  sheet  of  paper.  Surveys  are  plentiful  within  the  Navy  and  it  was  deemed  important 
not  to  impose  upon  the  fleet.  The  cover  letter  stated  it  should  take  no  longer  than  ten 
minutes  to  complete  the  survey. 

Since  many  of  the  requirements  to  host  an  on-line  system  are  not  in  the  fleet,  it  was 
important  to  place  a  disclaimer  at  the  top  of  the  survey.  The  following  note  was  included: 
Although  you  may  not  currently  have  access  to  the  World  Wide  Web,  please  assume  you 
have  it  or  will  have  it  in  the  near  future  when  responding  to  these  questions.  Valid 
connectivity  concerns  and  availability  of  computer  hardware  surfaced  throughout  the 
responses  despite  our  effort. 

2.  Survey  Formulation 

A  cross-section  of  open  and  close-ended  questions  was  used  on  the  survey.  The 
open-ended  questions  were  designed  to  answer  the  following  questions; 

•  How  much  did  the  fleet  know  about  ongoing  initiatives?  What  did  they  think 
of  these  initiatives?  (Question  2) 

•  What  did  the  fleet  think  of  the  existing  navigation  planning  system?  Would 
they  be  willing  to  change  from  the  existing  publication  system  to  a  computer- 
based  system?  (Question  3) 

•  What  type  of  Navigation  Lessons  Learned  were  commands  maintaining  and 
how  much  importance  did  they  place  in  lessons  learned?  (Question  4) 

•  What  computer  hardware  did  users  feel  comfortable  with?  (Question  5) 

•  What  type  of  navigation  planning  information  had  been  sought  in  the  past  that 
was  important  to  include  in  a  single  data  repository  and  possibly  the  prototype? 
(Question  7,  Question  10,  Question  14) 

•  How  could  the  existing  navigation  feedback  systems  be  improved?  (Question 
13) 

The  closed-ended  questions  were  designed  to  achieve  the  following: 
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•  Where  should  we  focus  our  prototype  effort?  (Question  6) 

•  How  useful  is  the  existing  Navy  Tactical  Information  Compendium  (NTIC) 
Lessons  Learned  System  for  Navigation  planning?  (Question  8) 

•  How  much  time  is  spent  correcting  and  maintaining  navigation  sources  of 
information?  (Question  9) 

•  Which  fleet  and  commercial  systems  are  being  used  for  navigation  planning? 
(Question  11) 

In  Question  6  a  scale  was  provided  to  the  respondents  ranging  from  one  (Not 
Importcmt)  to  five  (Essential).  The  scale’s  intervals  were  assumed  equal  to  allow 
quantitative  analysis. 

3.  Data  Grouping 

Since  some  ships  sent  more  than  one  response  (as  requested),  it  was  necessary  to 
separate  the  data  to  keep  multiple  responses  from  influencing  command  specific  questions. 
The  entire  set  of  data  was  initially  grouped  into  two  categories;  all  responses  and  one 
response  per  command.  The  all  responses  category  was  used  to  compare  and  contrast 
groups  such  as  enlisted  versus  officer,  time  in  position,  or  command  types  (i.e.  ship  versus 
sub  responses).  A  junior  quartermaster  on  a  ship  who  took  the  time  to  fill  out  the  survey 
had  equal  weighting  with  an  executive  officer  of  the  same  ship.  The  one  response  per 
command  category  was  used  to  determine  the  number  of  ships  using  commercial  products, 
the  hours  spent  maintaining  publications,  or  the  type  of  lessons  learned  being  maintained. 
The  response  that  was  chosen  in  the  case  of  multiple  responses  per  unit  was  the 
navigator’s  or  the  job  title  of  a  respondent  that  came  closest  to  that  position. 

We  formed  a  hypothesis  that  we  might  see  a  distinction  in  results  among  senior 
and  junior  personnel.  Navigation  and  Operation  departments,  and  platform  size  and  types. 
Therefore,  demographic  data  was  collected  to  group  results  by  job  title,  time  in  billet, 
rank,  and  ship  type.  When  presenting  the  data,  the  groups  in  Table  2-1  are  used. 
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Table  2-1  Group  Compositions 


Group 

Ship  Classes/Explanation 

Large  Decks 

CVN,  CV,  LPH,  LHD,  LHA,  LCC,  MCS 

Small  Boys 

CG,DD,  DDG,  PC,  LPD,  LSD,  LST,  MCM,  MHC,  PC 

Crudes 

CG,  DD,  DDG,  FFG 

Amphibious 

LSD,  LPD,  LHD,  LPH,  LHA,  LCC 

Auxiliary 

AGF,  AGSS,  ARS 

Logistics 

AE,  AO,  AOE,  T-AFS,  T-AO 

Mine  Warfare 

MCM,  MCS,  MHC 

Submarines 

SSN,  SSBN 

Junior  Officers 

Ensign  up  to  and  including  Lieutenant  Commander 

B.  PRESENTATION  OF  COLLECTED  DATA 
1.  Respondent  Demographics 

Surveys  were  sent  to  396  separate  commands.  159  of  the  396  commands 
responded  for  a  return-rate  of  40.2%.  Due  to  multiple  responses  by  several  commands, 
238  total  responses  were  received.  Table  2-2  shows  ship  respondents  by  broad  categories 
and  percentages  of  their  respective  population.  Table  2-3  shows  similar  data  for  staff 
responses.  A  consistent  survey  response  rate  of  approximately  40%  was  achieved  across 
all  categories. 


Table  2-2  Ship  Responses 


Category 

Responses 

Population 

Percentage 

Carriers  (CV/CVN) 

6 

12 

50.0 

Cruisers  (CG/CGN) 

12 

27 

444 

Destroyers(DD/DDG) 

21 

56 

37.5 

Frigates  (FFG) 

16 

42 

38.1 

Amphibious 

13 

42 

31.0 

14 


Submarines 

30 

86 

34.9 

Mine  Warfare 

10 

24 

41.7 

Patrol  Craft  (PC) 

5 

13 

38.5 

Logistics 

11 

18 

61.1 

Auxiliary 

7 

11 

63.6 

Total 

131 

331 

39.6 

As  was  expected,  the  majority  of  responses  came  from  junior  officers  (0-1  through 
0-4)  holding  the  job  of  Navigator  between  12-36  months.  Demographic  data  on 
individual  respondents  is  shown  in  Figures  2-1  and  2-2. 


Table  2-3  Staff  Responses 


Category 

Responses 

Population 

Percentage 

CARGRU 

4 

8 

50.0 

CRUDESGRU 

2 

6 

33.3 

SUBGRU 

5 

5 

100 

PHIBGRU 

0 

3 

0 

DESRON 

7 

17 

42.2 

SUBRON 

3 

10 

30 

PHBRON 

4 

9 

44.4 

Total 

27 

63 

42.9 

15 


Appendix  C  contains  summary  information  in  numerical  format.  It  is  important  to 
note  that  in  Figure  C-1  of  Appendix  C,  there  is  an  overlap  between  the  job  title  of 
Assistant  Navigator  (ANAV),  Leading  Petty  Officer  (LPO)  and  Leading  Chief  Petty 
Officer  (LCPO).  The  numbers  in  the  figure  represent  the  titles  as  received  on  the  survey, 
but  in  fact  many  LPO’s  and  most  of  the  LCPO’s  are  also  the  ANAV. 


m  E-7  to  E-9 

103  37  l<=E-6 

□  Second  Officer* 
El  0-1  to  0-3 
44  10-4 

1  05  and  0-6 
1  Unknown 

I  *2"'' Officers  serve  on  Military  Sealift  Command  vessels 

Figure  2-1  Response  by  Rank 


Figure  2-2  Response  by  Months  in  Billet 


Although  comparing  and  contrasting  data  fi'om  the  various  groups  was  not  a 
primary  concern,  having  the  data  grouped  allowed  us  to  test  several  hypotheses; 

•  Were  enlisted  and  officer  opinions  significantly  different? 

•  Did  time  in  a  job  change  opinions? 
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•  How  did  navigator  and  quartermaster  responses  compare  to  operations  related 
job  positions? 

•  Did  ship  type  have  an  impact  on  results  received? 

Each  of  these  sub-groups  was  large  enough  to  provide  statistically  significant  information. 

2.  Statistical  Validity 

To  allow  valid  inference  about  a  population  based  on  a  sample,  it  is  important  that 
the  principle  of  randomness  be  embodied  in  the  sample  selection  procedure  [Ref  14:p. 
270].  With  our  sample  containing  only  the  returned  results  there  is  some  possible 
influence  on  the  randomness  of  the  sample.  We  assumed  the  US  Postal  Service  was  100% 
reliable  (in  fact  one  response  returned  with  an  open  envelope  and  no  survey  inside).  It  is 
presumed  that  commands  that  did  not  return  the  results  could  not  find  the  time,  lost  the 
survey,  or  simply  chose  not  to  respond.  For  our  purposes,  we  will  assume  one  of  the  first 
two  instances  and  therefore  this  principle  of  randomness  is  somewhat  intact.  Since  the 
observation  values  are  integers  between  one  and  five  for  Question  6,  the  population 
distribution  is  certainly  not  normal.  However,  thanks  to  the  Central  Limit  Theorem 
whatever  the  common  distribution  of  a  set  of  independent  random  variables,  provided  that 
their  variance  is  finite,  the  sum  or  average  of  a  moderately  large  number  of  them  will  be  a 
random  variable  with  a  distribution  close  to  the  normal  [Ref  14;p.  207]. 

To  determine  whether  the  samples  statistically  portray  their  respective  population, 
several  confidence  intervals  were  computed  for  groups  of  varying  sample  sizes.  Question 
6  of  the  survey  provided  guidance  toward  the  features  to  be  included  in  the  prototype. 
The  authors  felt  it  would  be  useful  to  include  pictures  of  aids  to  navigation  so  that  prior  to 
harbor  transits,  quartermasters  could  get  a  mental  image  of  the  aid.  When  shooting  visu^ 
bearings,  it  is  often  difficult  to  correlate  charted  aids  that  have  never  been  seen  with  actual 
navigation  aids  especially  if  the  surroundings  have  been  built  up  due  to  construction  or  if 
more  than  one  similar  aid  exists  (i.e.  multiple  radio  towers).  A  picture  can  ftliminatp  any 
confusion  and  like  the  cliche  it  is  worth  a  thousand  words.  Appendix  D  contains  the 
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calculations  for  the  statistics  contained  in  Table  2-3  using  the  Picture  responses  on  the 


survey. 


Table  2-4  Confid 

lence  Intervals 

Group 

Sample  Size 
(n) 

Sample  Mean  / 
Std  Dev  (sj 

Confidence 

Interval 

Computed  Population 
Mean 

Amphibious 

13 

4.29  /  .85 

95% 

3.78  <p  <4.80 

Amphibious 

13 

90% 

3.87  <n  <4.71 

Amphibious 

13 

80% 

3.97  <p <4.61 

Navigators 

103 

4.19/. 71 

99% 

4.01  <  (X  <  4.37 

Navigators 

103 

95% 

4.05  <  p  <  4.33 

Navigators 

103 

90% 

4.08  <n<  4.32 

All  Respondents 

238 

4. 10/. 94 

99% 

3.94<p<4.26 

All  Respondents 

238 

95% 

3.98  <n<  4.22 

All  Respondents 

238 

90% 

4.00  <  |x  <  4.20 

Observing  the  confidence  intervals  for  the  population  means,  even  the  smallest 
sample  group  of  amphibious  respondents  provides  a  tight  enough  interval  for  our 
purposes.  By  relaxing  the  confidence  to  80%,  one  can  hypothesize  that  the  entire 
population  of  amphibious  ships  (42)  find  having  pictures  included  in  the  prototype 
important  (4  on  the  scale  of  1  -  5). 

The  information  obtained  from  the  surveys  follows  by  question  number.  In  many 
of  the  tables,  the  two  groups  of  responses  are  compared:  All  Respondents  and  One 
Response  per  Command.  This  is  done  to  compare  and  contrast  the  Navigator/Navigation 
Plans  Officer  responses  with  all  returned  samples. 

3.  Systems  Hardware  Results 


a)  Question  3:  Type  of  Planning  System  Desired 

The  overwhelming  majority  (68%)  of  respondents  stated  they  would  prefer 
an  online  system  compared  to  the  current  publication  system  (Table  2-5).  “On-line”  was 
not  defined,  but  most  respondents  interpreted  this  as  computerized  and  not  necessarily 
connected  to  the  Internet  or  a  network.  Many  stated  the  “on-line”  system  would  save 
space — ^notably  Patrol  Craft  (PC),  Mine  Countermeasure  Ships  (MCM),  and  Submarines. 
On  the  other  hand,  these  same  individuals  expressed  concern  for  the  availability  of 


18 


computer  assets.  Typically,  smaller  ships  have  far  less  computer  assets  and  less 
telecommunications  connectivity  capability.  Many  felt  an  online  system  could  reduce  their 
workload  on  correcting  publications  and  charts.  The  35  respondents  who  stated  they 
wanted  both  an  online  and  hard  copy  publication  capability  for  the  most  part  stated  they 
did  not  trust  an  “online”  source  to  have  the  reliability  necessary  for  a  navigation  planning 
system.  The  23  respondents  who  stated  they  wanted  to  maintain  the  current  publication 
system  primarily  did  not  see  the  cost  benefit  of  introducing  a  new  system.  Both  the 
reliabihty  and  cost  issues  are  valid  and  will  be  addressed  in  later  chapters.  There  was  very 
little  difference  between  the  two  groups  of  information.  The  results  are  listed  in  the 
following  table. 


Table  2-5  Question  3  Navigation  Planning  System 


Answer 

One 

Result/Command 

Percentage 

All 

Respondents 

Percentage 

Online 

112 

69 

160 

68 

Both 

23 

14 

35 

15 

Publication 

19 

12 

23 

10 

Neither 

3 

2 

5 

2 

No  Response 

5 

•  3 

13 

5 

b)  Question  5:  Configuration  for  a  Consolidated  location  or 

“Library”  of  electronic  Navigation  Information 

Question  5  was  intended  to  gauge  the  wilUngness  of  individuals  to  embrace 
technology.  It  was  also  written  in  an  intentionally  ambiguous  way  using  “configuration” 
so  as  not  to  influence  the  results  toward  a  certain  technology  and  to  see  what  new  ideas 
could  be  generated.  It  may  have  been  too  ambiguous  since  many  respondents  stated  they 
did  not  understand  what  was  meant  by  “configuration”.  Many  declined  to  answer  the 
question  (33%  of  all  responses).  Those  that  did  answer  overwhelmingly  felt  CD-ROM 
would  be  the  medium  of  choice  (Table  2-6).  Not  only  are  CD-ROMs  a  very  logical  choice 
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for  a  “library”  of  electronic  information,  but  the  National  Imagery  and  Mapping  Agency 
(NIMA)  is  currently  digitizing  publications  and  distributing  them  on  CD-ROM.  Only  a 
handful  of  publications  (Sailing  Directions,  Port  Directory  etc.)  have  actually  been 
introduced  to  the  fleet,  but  this  may  have  influenced  the  survey  responses.  This 
digitization  is  a  start  in  the  right  direction,  but  is  primarily  aimed  at  paperwork  reduction. 
An  interactive  program  where  all  sources  of  information  including  graphics  can  be  queried 
and  searched  would  be  more  ideal. 

Ideas  submitted  for  the  Other  category  included  updated  disk  distributed 
quarterly;  user  friendly;  Navigation  Sensor  System  Interface  (NAVSSI)  compatible;  and 
JMCIS  resident. 


Table  2-6  Question  5  Configuration 


Question  5  Results 

One 

Result/Command 

Percentage 

All 

Respondents 

Percentage 

CD-ROM 

58 

35 

82 

34 

WWW 

10 

6 

16 

7 

WWW/CD-ROM 

5 

3 

7 

3 

Online 

3 

2 

4 

2 

Other 

42 

25 

51 

21 

Blank  Response 

A1 

28 

78 

33 

4.  Lessons  Learned  Results 


a)  Question  4:  Lessons  Learned  “library”  Currently  Maintained 

This  question  was  intended  to  measure  not  only  what  commands 
maintained,  but  also  gain  insight  on  the  value  that  they  placed  on  lessons  learned.  The 
range  of  answers  was  quite  broad  from  “none”  to  “binders  containing  information  on  each 
harbor  transit.”  The  responses  (Table  2-7)  were  grouped  into  the  following  categories: 


20 


None,  Safety/Mishaps,  Port  Visits,  Lessons  Learned,  Nav  Briefs,  and  Other.  None  was 
only  tallied  if  the  command  actually  stated  “none”.  The  rather  broad  category  of  Lessons 
Learned  was  marked  if  the  command  was  not  specific  in  their  response  but  made  any 
mention  of  maintaining  some  aspect  of  lessons  such  as  message  traffic.  Had  we  asked 
them  to  mark  boxes  of  the  categories,  more  accurate  data  would  have  been  collected. 
Unfortunately,  by  giving  the  categories  to  the  respondents,  we  felt  we  might  influence 
their  answer — no  command  wants  to  admit  they  don’t  maintain  a  file  on  safety  messages, 
port  visits  or  navigation  details.  With  an  open-ended  question,  the  tradeoff  was  less 
accurate  quantitative  data,  but  there  was  less  chance  of  simply  “checking  a  box.” 

Types  of  lessons  learned  categorized  as  Other  include:  Collision  briefs. 
Port  Directory,  Historical,  Check  rides,  NTIC  etc.  If  there  is  any  conclusion  to  be  drawn 
from  question  4,  it  is  that  surprisingly  few  commands  maintain  a  serious  navigation  lessons 
learned  libraiy.  The  fact  that  fiilly  25%  stated  None  or  did  not  respond  and  that  no  single 
category  was  above  38%  shows  considerable  room  for  improvement.  Although  the 
formulation  of  the  question  may  have  reduced  the  results,  many  commands  are  seemingly 
reinventing  the  wheel. 


Table  2-7  Question  4  Lessons  Learned  Maintained 


Question  4 

Number  Mentioned 

Percent  of  Commands 

None 

20 

12 

Safety/Mishap 

40 

24 

Port  Visit 

60 

36 

Lessons  Learned 

63 

38 

Navigation  Briefs 

14 

8 

Other 

16 

11 

No  Response 

21 

13 

21 


b)  Question  8:  Navy  Tactical  Information  Compendium  (NTIQ 
System 

The  NTIC  CD-ROMs  are  distributed  quarterly  to  the  fleet.  They  contain 
the  Navy’s  Lessons  Learned  System  (NLLS)  which  was  established  in  1991.  Before  that, 
no  formalized  methodology  for  collecting  and  distributing  lessons  learned  existed  within 
the  fleet.  The  initial  focus  was  limited  exclusively  to  operational  issues  that  had  proposed 
workarounds.  This  policy  excluded  substantial  information  in  other  areas  during  fleet 
operations  and  exercises.  For  the  purpose  of  this  system,  a  lesson  learned  is  information 
expressly  and  specifically  contributing  to  the  value  of  the  Navy’s  established  body  of 
knowledge  [Ref  10].  To  qualify  as  a  lesson  learned,  an  item  must  reflect  “value  added”  to 
existing  policy,  organization,  training,  education,  equipment,  tactics,  techniques  or 
doctrine  by  identifying  problems  areas.  The  NLLS  provides  a  responsive  method  for 
identifying  deficiencies  and  initiating  corrective  actions.  However,  this  approach  reduces 
lesson  learned  information  that  could  be  derived  from  policies  or  doctrine  that  work  and 
are  not  “problems”.  Somebody  preparing  for  a  similar  exercise  or  operation  could  gain 
confidence  or  insight  into  how  successful  policies  or  doctrine  worked.  In  an  effort  to 
minimize  the  database  and  focus  on  correctable  issues,  the  existing  system  excludes 
positive  feedback.  The  secondary  objective  is  to  minimize  the  system’s  cost  by  using  a 
text-based  database  system  to  collate,  evaluate  and  disseminate  Navy-specific  lessons 
learned.  The  system  allows  standard  search  queries  for  phrases  or  words.  It  is  compatible 
with  the  Joint  Universal  Lessons  Learned  System  [Ref  15]. 

Although  it  is  desired  that  all  lessons  learned  gravitate  toward  this  single 
system,  the  reality  is  that  many  navigation  lessons  learned  in  the  fleet  take  the  format  of 
after  action  messages  or  inputs  to  the  Port  Directory  Guide.  Searching  the  NLLS  reveals 
some  navigation  information,  but  far  from  a  comprehensive  database.  The  purpose  of  our 
asking  question  8  was  to  test  the  fleet’s  familiarity  with  the  system  as  well  as  see  if 
anybody  was  using  it  for  exercises,  transits,  port  visits  or  amphibious  operations.  The 
survey  results  indicate  the  system  is  a  failure  with  respect  to  navigation.  As  shown  in 
Table  2-8,  fully  47%  of  the  respondents  have  never  even  used  the  system  and  36%  more 
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use  it  less  than  once  per  month.  Those  using  the  system  do  not  appear  to  use  it  for  purely 
navigation  related  matters.  Our  survey  respondents  are  the  individuals  who  are  supposed 
to  submit  the  lessons  learned.  If  they  are  not  using  the  system  to  obtain  lessons  learned, 
this  may  indicate  why  so  few  navigation-related  lessons  learned  exist  within  the  system. 


Table  2-8  Navy  Lessons  Learned  System 


Frequency  NTIC  Use 

Responses 

Percent 

Type  of  NTIC  Use 

Responses 

Percent 

Never  Used  System 

112 

47 

Exercise 

38 

30 

Seldom  (<  1/Month) 

85 

36 

Transit 

4 

3 

Regularly  (>  1/Week) 

26 

11 

Port  Visit 

12 

10 

No  Responses 

14 

6 

Amphibious 

2 

2 

Exercise  &  Transit 

7 

6 

Transit  &  Port  Visit 

14 

11 

Exercise  &  Port  Visit 

14 

11 

Other  Combinations 

13 

10 

Other  Uses 

6 

5 

No  Response 

15 

12 

c)  Question  13:  Capturing  Fleet  Feedback  and  Navigation  Lessons 
Learned 

This  question  was  intended  to  generate  ideas  on  how  to  best  improve  the 
existing  lessons  learned  process.  The  Fleet  Intel  Collection  Manual  (FICM)/ONI  requires 
a  Port  Visit  Report  to  be  completed  by  select  ships  after  foreign  port  visits  [Ref  16],  This 
report  contains  useful  logistic  and  navigation  information,  but  the  enforcement  of  the 
report  and  redistribution  of  information  to  the  fleet  navigator  is  lacking  [Ref  17],  The 
current  methods  of  after  action  messages.  Port  Directory  inputs,  FICM  reports,  and  the 
NLLS  are  designed  to  provide  only  qualitative  information.  No  system  is  in  place  to 
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actually  collect  data  and  generate  quantitative  results.  For  example,  a  simple  formatted 
survey  could  be  constructed  that  required  navigators  to  rank  the  pilots,  tugs,  navigation 
aids,  currents,  pier  fittings  or  other  aspects  of  the  navigation  detail.  Survey  questions 
could  also  collect  qualitative  commentary.  A  ship  preparing  for  a  foreign  harbor  transit 
could  query  the  database  by  ship  class,  timeframe,  or  response  type.  This  would  provide 
considerably  more  information  in  preparing  for  the  transit,  and  allow  greater  insight  into 
what  to  expect.  Since  we  envisioned  building  such  a  port  survey  into  the  prototype,  we 
didn’t  want  to  influence  the  respondents  and  used  an  open-ended  question  to  generate 
new  ideas. 

The  responses  were  quite  varied  and  ranged  from  “can’t  be  done”  to 
“establish  a  required  format.”  Many  brought  up  interesting  points  like  how  do  you 
validate  the  data  or  prevent  misinformation.  Some  saw  this  as  an  added  burden  and  felt 
the  system  was  already  in  place.  The  consensus  felt  a  required,  formatted  survey  would 
work  that  was  sent  to  a  central  database.  They  mentioned  surveys  could  be  uploaded  at 
the  earliest  opportunity  via  e-mail  or  via  the  WWW.  A  creative  response  mentioned  a  web 
site  could  list  critical  information  that  was  lacking  and  needed  to  populate  the  database.  It 
was  difficult  to  quantify  this  open-ended  question.  In  general,  the  positive  responses  far 
outweighed  the  negative,  which  indicated  people  saw  a  need  for  an  improved  system.  The 
results  of  question  13  are  in  Appendix  E. 

5.  Prototype  Information  Results 

a)  Question  6:  Importance  of  Navigation  Information  Sources 

To  aid  in  the  design  of  the  prototype,  question  6  gave  the  respondents  a 
chance  to  tell  us  how  important  different  types  of  information  would  be  if  accessible  in  a 
single  location  (system).  It  gave  us  a  chance  to  test  what  we  felt  was  important  to  include 
against  the  fleet’s  requirements.  Since  the  prototype  would  not  contain  all  information,  it 
also  helped  us  focus  our  efforts  on  what  the  fleet  found  most  important.  Using  the 
demographic  data,  this  question  provided  a  potential  wealth  of  statistical  and  grouping 
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analysis.  When  comparing  groups  of  responses  throughout  question  6,  what  actually 
stands  out  is  how  little  difference  truly  exists. 

Due  to  the  large  number  of  graphs  obtained  from  this  question,  they  have 
been  grouped  together  in  Appendix  F.  Graphs  F-1  and  F-2  provide  a  visual  depiction  of 
how  respondents  answered  on  the  scale  of  1  (Not  Important)  to  5  (Very  Important). 
Graph  F-1  is  for  all  respondents  and  F-2  is  the  One  Response/Command  group.  There  is 
very  little  difference  between  the  two  graphs.  The  same  data  grouped  by  percentages  is 
included  in  graphs  F-3  and  F-4.  What  is  obvious  from  these  four  graphs  is  the  relative 
importance  placed  on  the  categories  of  information: 

•  Port,  Meteorological  and  Safety  data  were  all  ranked  Very  Important  by  over 
50%  of  the  respondents.  Over  90%  of  the  respondents  ranked  Port  and 
Meteorological  data  Important  or  Very  Important. 

•  Over  85%  of  the  respondents  ranked  Pictures,  Lessons  Learned,  and  Safety  as 
Important  or  Very  Important. 

•  Digital  Pubs  and  Digital  Charts  received  very  similar  support  with  79%  ranking 
them  Important  or  Very  Important. 

•  Exercise  and  Imagery  data  followed  with  decreasing  support  and  more 
dispersed  answers. 

•  Amphibious  data  received  the  least  support  but  this  is  likely  due  to  the  small 
number  of  ships  that  directly  participate  in  these  operations. 

Each  of  the  remaining  graphs  in  Appendix  F  compare  demographic  groups 
and  provides  the  average  response,  the  standard  deviation,  and  the  mode.  These  three 
statistics  are  provided  to  allow  full  interpretation  of  the  data.  To  begin  the  group  analysis. 
Graph  F-5  was  constructed  to  compare  every  sub-group  and  uncover  significant 
anomalies.  The  lines  between  data  points  are  insignificant,  but  leaving  them  in  the  graphs 
aids  in  seeing  trends  and  finding  specific  data  points  within  tight  groups  of  data. 

When  observing  the  data,  several  questions  can  be  asked.  How  far  out 
must  a  sample  group  lie  to  be  significant?  More  to  the  point,  does  it  matter  whether  large 
deck  ships  think  safety  is  .5  higher  on  the  scale  than  the  remainder  of  the  groups?  The 
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deck  ships  think  safety  is  .5  higher  on  the  scale  than  the  remainder  of  the  groups?  The 
statistical  formulas  exist  to  test  for  the  difference  between  population  means,  but  the 
results  did  not  prove  tremendously  useful.  What  was  more  interesting  and  insightful  was 
to  construct  several  graphs  comparing  logical  groups,  observe  the  data  trends,  and 
interpret  the  suggested  results.  The  Navy  is  an  organization  full  of  communities  rich  in 
heritage.  The  greatest  value  of  breaking  the  data  into  groups  may  likely  be  the  ability  of 
the  reader  to  see  how  “their  community”  answered. 

Graph  F-5  illustrates  the  strong  support  by  all  groups  for  the  various  types 
of  information.  As  expected,  amphibious  ships  ranked  the  amphibious  data  between 
Important  and  Very  Important.  Submariners  who  rarely  operate  in  that  regime  gave  that 
category  the  lowest  mmk.  Graph  F-6  shows  Ship  versus  Sub  versus  Staff  responses.  The 
data  suggests  staffs  find  digital  pubs,  imagery,  amphibious  and  exercise  data  more 
important  than  submariners  do  with  ships  falling  in-between.  This  correlates  with  each  of 
these  groups’  special  needs  to  conduct  their  primary  missions.  All  three  groups  were  in 
very  close  agreement  with  the  importance  of  pictures,  lessons  learned,  safety  and  port 
data.  Graph  F-7  further  broke  down  the  commands  by  specifying  ship  types.  In  addition 
to  the  amphibious  data  as  mentioned  before,  large  deck  ships  stand  out  on  the  importance 
of  safety  data.  Graph  F-8  compares  big  deck  ships  with  small  boys.  Many  small  boys 
had  mentioned  the  space  saving  convenience  of  digitizing  pubs  in  the  open-ended 
questions.  The  data  contained  in  this  graph  supports  this  notion. 

The  next  series  of  groups  compared  job  titles  and  ranks.  Graph  F-9 
compares  Operations  Officers  with  Navigators.  Very  few  differences  exist  except  to  note 
that  Navigators  find  pictures  more  important  (they  of  course  would  primarily  be  the  ones 
using  them)  and  Operations  Officers  find  amphibious  and  exercise  data  more  important. 
Graph  F-10  tried  to  show  difference  based  on  time  within  the  job.  Nothing  particularly 
significant  stood  out.  Graph  F-1 1  broke  the  results  out  by  rank  of  the  respondent.  The 
data  suggests  the  young  quartermaster  out  shooting  navigation  aids  find  pictures  more 
important  than  the  senior  enlisted  who  has  done  it  “the  hard  way”  throughout  his  career. 
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Similarly,  the  E-6  and  below  who  must  maintain  and  retrieve  a  publication  from  the  chart 
room  found  digital  pubs  more  important  than  the  Lieutenant  Commander  and  above  who 
may  on  occasion  read  the  publication.  There  was  a  perplexing  and  sizable  spread  (.7) 
with  respect  to  exercise  data  between  E-6  and  below  ranking  it  the  highest  and  0-4  and 
above  the  lowest.  Once  again,  the  value  added  by  grouping  the  data  and  comparing  may 
be  nothing  more  than  an  appreciation  for  sub-cultures  within  the  Navy.  The  significant 
result  to  take  away  from  question  6  is  the  fact  that  the  vast  majority  of  individuals  place  a 
high  level  of  importance  in  almost  every  one  of  these  categories. 

b)  Question  7, 10  &  14:  Additional  Data  Sources  Desired,  Missing 
Information  Obtained  from  Other  Commands,  and  Comments 
and  Suggestions 

These  three  questions  were  open-ended  with  the  intent  of  obtaining  the 
overlooked  or  original  idea.  Many  terrific  ideas  were  obtained  and  Appendix  E  contains 
the  vast  majority  of  them.  The  following  short  list  provides  a  sample  of  suggestions  to 
include  in  a  planning  system: 

•  Harbor  regulations,  Bridge  to  Bridge  channel  information.  Vessel  Traffic 
Scheme  manuals 

•  Quality  of  Navigation  aids  used  for  head  bearings  and  drop  bearings  when 
anchoring 

•  Sanitized  Navigation  Mishap  Reports  and  Lessons  Learned  for  Training 
Evolutions 

•  Schedules  Database  for  CINCLANTFLT  or  CINCPACFLT 

•  Oil  Rigs,  Fishing  Areas  and  Merchant  Shipping  Lanes 

•  Amphibious  Beach  Surveys 

•  Feedback  section  for  inaccuracies  found  in  existing  publications 

•  Foreign  Charts  and  Publications  (such  as  British  Admiralty  Charts) 

•  Husbanding  Agent  e-mail  addresses  and  phone  numbers 
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6.  Existing  Navigation  Tools 


a)  Question  11:  Current  Systems  in  Use  for  Navigation  Planning 

There  are  many  systems  that  can  be  used  for  voyage  planning,  computing 
sunrise/simset  or  plotting  tides  and  currents.  Most  of  them  are  commercial  products  that 
must  be  purchased  out  of  the  ship’s  budget.  This  question  was  included  to  gain  insight 
into  what  is  already  being  used  in  the  fleet.  The  results  were  quite  interesting.  107 
Commands  marked  that  they  used  a  commercial  product.  Sixty  or  56%  of  the  commands 
are  using  a  commercial  software  program  called  the  Cap’n  which  contains  many  features 
for  voyage  planning,  electronic  charting,  chart  inventory,  celestial  computations  and  tides 
and  currents  (Chapter  I).  It  is  designed  to  operate  on  a  desktop  PC.  Having  used  an 
earlier  version  of  the  Cap’n  as  a  Navigator  for  voyage  planning,  it  was  easy  to  understand 
the  timesaving  that  could  be  achieved.  Purchasing  electronic  charting  capabilities  can  be 
prohibitively  expensive  for  individual  ships  and  we  did  not  measure  how  many 
commands  have  actually  purchased  this  feature.  The  Navy’s  current  development  of 
NAVSSI,  which  is  slowly  being  installed  on  ships  and  recently  introduced  in  the 
Navigation  Schoolhouses  in  July  1997  [Ref  18],  will  provide  many  similar  features  of  the 
Cap’n  product.  A  comparison  of  the  two  products  would  make  for  an  interesting  study  of 
Commercial  Off-the-Shelf  (COTS)  software  technology. 

There  was  no  other  commercial  product  mentioned  with  such  frequency. 
Stella  is  a  celestial  computation  software  that  is  freely  distributed  to  ships  (may  not  have 
been  considered  a  commercial  product  by  many  respondents)  and  received  the  next 
highest  response  rate  with  13.  Other  products  that  received  mention  include:  Navtrek  (1), 
Micronautics  (1),  Tru-Chart  (1),  Sperry  ECDIS  (3),  Chart  Nav  (1),  Waypoint  for 
Windows  (2),  and  various  tides  and  current  programs. 

Access  to  GCCS,  JDISS,  and  WWW  systems  onboard  ship  is  currently 
limited  to  the  upper  level  staffs  and  large  deck  platforms.  It  is  not  surprising  that  these 
systems  were  not  marked  more  frequently.  The  results  are  contained  in  Table  2-9. 
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Table  2-  9  Systems  Used  for  Navigation  Planning 


System 

GCCS 

WWW 

JDISS 

Commercial 

Used 

9 

25 

14 

107 

No  Response 

153 

138 

148 

55 

b)  Question  9:  Time  Spent  Maintaining  and  Correcting  Hardcopy 
Materials 

To  ensure  safety  of  navigation,  publications  and  charts  require  continuous 
maintenance  as  weekly  changes  are  annovmced  (Notice  to  Mariners  and  Local  Notice  to 
Mariners).  A  set  of  charts  and  publications  used  regularly  must  always  be  kept  up  to  date 
[Ref  18].  Charts  and  publications  that  are  maintained  in  inventory  for  an  overseas 
deployment  or  that  are  rarely  used  will  have  a  Chart  Card  associated  with  them.  The  card 
will  be  “charged”  or  annotated  if  an  outstanding  correction  must  be  made  before  use. 
Much  of  the  quartermaster’s  time  is  spent  conducting  this  necessary  maintenance.  This 
extremely  labor  intensive  process  requires  meticulous  attention  and  can  be  susceptible  to 
hviman  error.  Until  a  system  can  be  devised  that  provides  standardized,  automatic 
electronic  corrections  little  will  change.  A  conceptual  system  might  have  publications  on 
CD-ROM  with  a  “Correction  Database”  cross-checked  before  the  information  is 
presented.  This  “Correction  Database”  could  be  in  the  form  of  a  3 -‘A  inch  diskette  mailed 
weekly  or  a  download  from  an  online  update. 

This  question  was  included  for  completeness  and  as  an  opportunity  to 
gather  fleet  wide  statistics.  If  the  process  could  be  automated,  signiflcant  man-hours 
could  be  saved.  Another  advantage  would  be  reduction  of  errors.  The  standard  deviations 


29 


of  the  results  in  Table  2-10  were  extremely  high.  This  can  be  partially  attributed  to  the 
variety  of  operating  environments  and  partially  to  the  difficulty  in  Navigators  accurately 
estimating  or  averaging  these  tasks.  This  data  is  not  typically  maintained  or  tracked  by 
Navigators,  although  mapping  this  process  may  uncover  some  interesting  results. 


Table  2-10  Weekly  Maintenance  Hours 


Question  9 

Hydro  and  NOT  AM 
Files 

Nav 

Publications 

Nav  Charts 

Other 

Hours 

4.4 

11 

12.1 

10.9 

Standard 

4.4 

7.1 

14.2 

8.4 

Deviation 

C.  REQUIREMENTS  VERSUS  ONGOING  INITIATIVES 

There  are  several  initiatives  that  are  underway  to  improve  navigation  within  the 
fleet.  The  most  notable  is  Navigation  Sensor  System  Interface  (NAVSSI),  which 
provides  electronic  charting  tools,  voyage  planning,  and  integration  with  GPS  and  other 
navigation  sources.  Publications  are  also  being  digitized  and  distributed  on  CD-ROM  by 
NIMA.  The  Navy  Lessons  Learned  System  exists,  but  it  is  underutilized  by  the 
navigation  community.  Designed  to  be  a  low  cost,  low  maintenance  system,  it  does  not 
provide  the  search  tools,  graphics  or  data  capable  in  today’s  information  age.  Since  this 
initiative  to  digitize  is  well  underway  by  NIMA  [Ref  19],  the  focus  of  our  research  has 
been  on  filling  the  information  void  for  Navigation  Planning.  Ideally,  the  data  gained 
from  the  users  in  this  survey  will  help  shape  the  future  collection  and  dissemination  of 
navigation  information. 

Every  idea  mentioned  within  the  surveys  is  technologically  feasible.  The  fleet  is 
willing  to  embrace  a  better  system.  The  primary  challenge  for  the  remainder  of  this  thesis 
is  to  develop  a  system  recommendation  that  maximizes  data  interchange  while 
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minimizing  development  and  maintenance  costs.  The  secondary  challenge  is  to  make  it 
simple  so  that  it  gets  used.  The  third  and  final  challenge  is  to  make  it  compatible  with 
existing  systems  so  it  is  not  yet  another  stovepipe. 

D.  SUMMARY  OF  REQUIREMENTS  ANALYSIS 

Many  of  the  responses  included  typewritten  letters,  provided  literature  on 
commercial  products  or  named  points  of  contact  for  further  research.  The  overall  quality 
and  quantity  of  data  returned  exceeded  our  expectations.  Although  we  envisioned 
conducting  comprehensive  statistical  analysis  comparing  groups  of  data,  the  large  sample 
sizes  and  consistency  across  groups  negated  much  of  the  statistical  analysis.  Conducting 
the  survey  and  interpreting  the  vast  quantity  of  information  provided  the  following 
tangible  benefits: 

•  Validated  many  assumptions 

•  Allowed  user  input  into  system  development 

•  Provided  direction  for  a  new  prototype  navigation  planning  tool 

•  Showed  how  willing  the  fleet  is  to  embrace  new  technology 

It  also  may  provide  the  intangible  benefit  of  improving  future  acceptance  and  use  of  a 
new  Navigation  Planning  System  should  it  get  introduced  to  the  fleet. 

Taking  into  account  the  survey  results,  a  system  architecture  that  meets  the  needs 
of  the  fleet  would  contain  two  overlapping  systems: 

•  A  relational  database  updated  with  current  information  and  distributed  to  the 
fleet  periodically  (quarterly)  on  CD-ROM.  Monthly  diskettes  could  be 
distributed  with  information  deemed  critical. 

•  A  Client-server  architecture  with  the  most  current  database  on  the  server  to 
allow  clients  access  to  the  newest  information  through  a  browser.  Last 
updated  dates  could  be  used  liberally  to  minimize  connectivity  times  for  ships 
at  sea. 

An  absolute  key  to  making  this  database  concept  successful  is  obtaining  quality  inputs 
from  the  fleet.  Formatted  surveys  to  capture  feedback  would  be  an  integral  part  of  the 
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database.  This  data  along  with  digitized  pictures  could  be  sent  via  diskette  or 
electronically  uploaded  when  feasible.  With  IT-21  mandating  Office  ’97  as  the  software 
of  choice  [Ref.  13],  Access  was  chosen  for  our  prototype  database.  IT-21  also  solves  the 
need  for  personal  computers  with  more  than  enough  power  to  run  such  an  application. 
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III.  MIGRATION  ALTERNATIVES  FOR  A  NAVIGATION  PLANNING 

SYSTEM 

A.  DEVELOPING  ALTERNATIVES 

Migrating  from  the  current  manual  navigation  plaiming  method  to  an  automated 
method  should  be  done  carefully.  The  current  repository  of  data  and  the  process  of 
collecting  maritime  navigation  information  in  the  form  of  hard  copy  charts,  publications, 
updates,  and  computer  products  has  evolved  in  the  U.  S.  Navy  over  two  centuries.  In  this 
chapter  several  different  migration  paths  (manual  to  automated)  will  be  explored,  and 
some  of  the  key  pros  and  cons  of  the  options  will  be  weighed.  Fleet  users,  in  one  form  or 
another,  suggested  all  migration  options  (Appendix  E). 

The  current  manual  method  of  navigation  planning  (described  in  Chapter  I)  has  its 
greatest  strength  in  that  it  is  accurate  and  reliable.  U.S.  Government  agencies  that  collect, 
produce,  and  disseminate  navigation  information  are  well  established  and  have  spent 
many  decades  developing  the  know-how  and  infrastructure  to  accomplish  their  mission. 
The  greatest  weakness  of  current  navigation  plaiming  is  that  it  is  extremely  labor 
intensive.  According  to  fleet  users,  the  average  “unit”  (e.g.,  ship,  submarine,  or  afloat 
staff)  spends  nearly  35  man  hours  per  week  keeping  their  hard-copy  navigation  products 
(charts  and  publications)  corrected  and  up-to-date  (Chapter  II  Table  2-10).  When  ships 
are  operating  at  sea,  many  more  additional  hours  are  spent  collecting  and  filtering  this  up- 
to-date  navigation  data  into  informative  navigation  plans  and  briefs.  Alternatives 
therefore  should  be  developed  to  use  state  of  the  art  computer  technology  to  help  reduce 
the  number  of  man-hours  being  spent  by  fleet  units  on  the  maintenance  and  assembly  of 
navigation  information. 

A  broad  range  of  naval  personnel,  ranging  from  Navy  captains  (pay  grade  0-6)  to 
third  class  petty  officers  (pay  grade  E-4)  provided  the  fleet  survey  feedback  discussed  in 
Chapter  II.  Based  upon  this  fleet  feedback,  there  is  overwhelming  support  for  migrating 
fi-om  the  current  cumbersome  manual  navigation  planning  process  to  a  more  efficient 
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automated  method  (Appendix  E).  This  need  to  “digitize”  all  aspects  of  navigation  is  also 
well  recognized  by  NIMA,  and  has  been  clearly  articulated  in  their  publication  entitled 
Digitizing  the  Future.  In  addition,  a  new  navigation  demonstration  software  package 
called  the  Full  Utility  Navigation  Demonstration  (FUND)  has  just  been  released  by 
NIMA  in  December  1997.  This  program  reportedly  accepts  digital  nautical  charts  and  has 
some  voyage  planning  capability  [Ref.  20]. 

B.  TECHNOLOGY  OPTIONS 

Several  ship  navigation  programs,  both  military  and  commercial,  already  exist  in 
the  fleet,  as  described  earlier.  The  key  functionality  which  should  be  added  to  current 
voyage  planning  tools  is  the  ability  to  instantly  access  and  accept  any  and  all  structured 
and  imstructured  digital  navigation  products,  ranging  from  nautical  charts  to  publications 
to  database  information. 

The  following  existing  computer  technologies  are  appropriate  for  these  tasks: 

1.  Computer  Hard-Drive  Resident  Program 

The  Naval  Sea  Systems  Command  (NAVSEA)  Navigation  Sensor  System 
Interface  (NAVSSI),  described  earlier,  is  an  example  of  a  navigation  program  designed  to 
permanently  reside  on  a  shipboard  computer  hard-drive.  NAVSSI  was  designed  as  a 
software  layer  to  ride  on  top  of  the  Joint  Maritime  Communications  Information  System. 
JCMIS  runs  aboard  ship  on  the  NAVSEA  TAC-3  or  TAC-4  computer  workstation,  which 
uses  the  UNIX  operating  system.  Other  hard-drive  resident  navigation  programs  are 
designed  for  personal  computers,  such  as  the  Cap’n  program. 

All  hard-drive  resident  programs  can  operate  in  a  stand-alone  mode  on  a  single 
computer,  and  many  are  designed  to  be  accessed  and  used  remotely  via  distributed 
computer  networks  and  client-server  configurations. 

The  benefits  of  maintaining  a  navigation  program  on  the  local  hard  drive  include 
[Ref.  21]: 
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•  If  the  computer  network  suffers  a  casualty,  it  can  still  operate  in  stand-alone 
mode  on  the  local  platform  until  the  network  is  restored. 

•  The  security  of  the  program  and  data  may  be  enhanced  if  robust  security 
features  and  access  controls  are  maintained  on  a  “local”  computer  (and  not 
across  the  entire  network). 

•  Better  control  over  standardization  of  software  can  be  accomplished  with 
hard-drive  resident  programs  versus  Intranet  or  Internet  available  programs, 
which  may  have  many  hundreds  or  thousands  of  users.  Current  rigid  U.  S. 
Navy  version  control  and  distribution  of  IT-21  compliant  software  helps  to 
support  the  concept  of  standardization  [Ref.  13]. 


The  disadvantages  of  a  Hard-Drive  resident  Navigation  program  and  data  include 
[Ref.  21]: 

•  Islands  of  information  -  different  platform  capabilities 

•  Possible  multiple  data  formats  -  hard  to  share  data 

•  Multiple  interfaces 

•  Multiple  protocols 

•  Support  costs  for  each  platform/station 


2.  Removable  Media  Updates  to  Hard-Drive  Resident  Programs 

Any  hard  drive  resident  navigation  program  must  have  some  means  of  updating  or 
revising  both  the  operating  program  and  the  navigation  data  used.  This  is  necessary 
because  navigation  data  is  often  inherently  perishable,  and  software  is  always  being 
improved.  For  example,  a  meteorological  phenomenon  such  as  a  tropical  storm  might 
completely  change  the  characteristics  of  a  Caribbean  port’s  ship  berths.  Storm-driven 
silting  may  occur  in  some  areas  of  the  inner  harbor,  and  this  condition  would  need  to  be 
immediately  promulgated  to  potential  visitors  to  the  port.  A  “Notice  to  Mariners” 
(NOT AM)  message  would  currently  be  broadcast  to  the  fleet  to  inform  ships  of  the  silted 
harbor  hazard.  In  addition,  the  storm  may  cause  other  long-term  changes  to  the  port  and 
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services  available  there  which  may  affect  navigational  publications  covering  the  region. 
Herein  lies  the  need  to  be  able  to  update  the  navigational  data  resident  on  a  computer  hard 
drive,  which  may  include  charts  and  port  publications  for  our  example  Caribbean  port. 

One  method  of  updating  the  hard  drive  would  be  to  distribute  a  floppy  disk  update 
to  the  appropriate  ships.  The  standard  3-1/2  inch  floppy  disk  is  removable  and  may 
contain  up  to  1.44  megabytes  (Mb)  of  data  after  formatting.  Other  removable  storage 
media  which  could  be  used  for  updates  include  the  3.5  inch  zip  drive,  which  can  store  100 
Mb  of  data,  and  the  4.75  inch  ISO  9000  format  Compact  Disk  (CD),  which  can  store  up 
to  660  Mb  of  data  [Ref.  22  :p.  130].  All  of  these  portable  storage  devices  would  have  to  be 
mailed  or  otherwise  shipped  to  an  afloat  command  to  periodically  update  navigation 
software  and  data.  Fleet  feedback  has  indicated  that  such  updates  should  occur  anywhere 
from  monthly  to  annually,  with  quarterly  revisions  being  the  most  common 
recommendation  for  routine,  non-emergency  updates. 

CD  optical  disk  technology  has  become  popular  in  the  1990s,  because  it  is 
inexpensive  and  so  well  suited  for  storing  massive  amounts  of  data.  CDs  were  designed 
to  store  encoded  digital  information,  such  as  up  to  100,000  pages  of  text  [Ref  23  ;p.  101]. 
This  is  over  400  times  the  3.5-inch  high-density  floppy  disk  storage  capability.  In 
addition,  plastic  CDs  have  other  advantages  over  floppy  disks;  they  are  less  vulnerable  to 
magnetism,  dirt,  or  rough  handling  [Ref  22:p.  131].  Several  different  forms  of  CDs  exist. 
CD-Read  Only  Memory  (CD-ROM)  is  the  most  common  and  is  intended  for  mass 
distribution  of  data.  Other  forms  of  CD  technology  include  CD  recordable  (CD-R)  which 
are  write  once,  read  many  and  CD  read-writeable  (CD-RW)  which  have  the  same 
functionality  as  floppy  disks.  CD  Optical  jukeboxes  are  a  new  innovation,  which  offer  an 
inexpensive  way  to  archive  huge  amounts  of  data  with  interchangeable  libraries  of 
stacked  CDs. 
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3. 


World  Wide  Web  or  “Online”  System 


Yet  another  automated  migration  alternative  might  be  to  make  the  navigation 
planning  program  and  data  available  through  a  large  computer  network  such  as  an 
intranet  or  the  Internet.  By  taking  advantage  of  a  distributed  computing  environment  and 
a  client-server  architecture,  any  number  of  fleet  users  could  conceivably  capitalize  on  the 
information  “power”  available  from  a  modem  World  Wide  Web  navigation  tool,  for 
example.  Updates  could  be  rapidly  transmitted  over  a  network  to  a  large  number  of 
users,  thereby  eliminating  shipping  costs  and  getting  the  information  to  users  much  faster. 

Other  advantages  of  a  Web-based  Navigation  Program  and  data  [Ref.  22:  pp.  4-5]: 

•  Platform  independence 

•  Multiple  data  formats  can  be  accommodated 

•  Single  interface 

•  Uses  common  protocols 

•  Easier  to  disseminate  and  share  information 

•  Minimizes  ongoing  support  costs 

•  Permits  leveraging  scarce  computing  resources 

C.  OTHER  ISSUES  WITH  A  WEB-BASED  NAVIGATION  PROGRAM 

1.  Bandwidth 

Any  computer  networks  designed  for  use  at  sea  must  be  designed  with  bandwidth 
in  mind.  Due  to  the  inherently  mobile  nature  of  sea-based  forces,  satellite  and  long-haul 
radio  links  must  be  employed  for  information  exchange.  Appropriate  radio  frequency 
bandwidth  must  be  allocated  within  the  available  spectrum  to  support  the  transmission 
and  reception  of  massive  amounts  of  data. 

In  addition  to  bandwidth  availability,  the  information  capacity  of  the  system  is  an 
important  design  consideration.  The  current  typical  “low-end”  at-sea  computer  network 
has  a  T1  bit  rate:  1.544  Megabits  per  second  (MBPS)  [Ref.  24].  This  is  being  improved 
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as  new  initiatives  to  increase  capacity  are  integrated  into  the  fleet  such  as  the  Automated 
Digital  Network  System  (ADNS). 

2.  System  Security  and  Data  Vulnerability 

Networked  computer  resources  and  data  have  an  inherently  increased  risk  of 
corruption  and  unauthorized  access  due  to  the  large  number  of  users  who  have  access  to 
the  network  at  any  given  time.  A  stand-alone  personal  computer  typically  has  fewer 
users  with  access  to  it  and  therefore  has  a  lower  associated  security  risk.  The  current 
manual  hard-copy  navigation  planning  data  also  has  fewer  users  who  have  direct  access 
to  it  than  if  this  same  data  were  digitized  and  made  available  to  the  masses  on  a  large 
network.  Although  the  vast  majority  of  navigation  planning  software  and  data  is 
unclassified  (with  much  of  it  commercially  available  or  in  the  public  domain)  there  exists 
a  significant  data  vulnerability  issue.  If  this  unclassified  navigation  data  were  placed  in  an 
open  database  and  made  available  to  the  public  via  the  World  Wide  Web  (WWW),  a 
computer  “hacker”  might  gain  access  to  the  database  and  alter  critical  information.  For 
example,  a  chart  that  shows  a  reef  near  a  port  entr2ince  could  be  modified  to  delete  the 
reef  and  show  safe  water  in  its  place.  An  unsuspecting  mariner  might  access  this 
corrupted  data  and  use  it  in  good  faith  to  navigate  into  port,  subsequently  running 
aground  on  the  “ghost”  reef.  This  example  illustrates  that  although  navigation 
information  is  wholly  unclassified,  the  database  or  other  data  sources  must  be  protected  to 
prevent  unauthorized  access  or  malicious  tampering.  The  safety  of  marine  navigation 
would  therefore  largely  depend  upon  the  strength  of  the  database  security  features.  At  a 
minimum,  the  data  source  (database)  should  be  designed  with  appropriate  computer 
security  features  such  as  robust  encryption  (to  protect  the  data)  and  password  protection 
to  validate  authorized  users  to  the  system.  The  ideal  system  would  also  include  a  secure 
computer  network  to  permit  safe  data  transmission  and  reception.  If  the  system  were  to 
migrate  to  the  SIPRNET  or  NIPRNET,  the  security  and  password  schemes  used  by 
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similar  applications  on  those  networks  would  be  sufficient  for  a  full-scale  fleet  version  of 
GatorNet. 


3.  Connectivity 

Numerous  fleet  users  expressed  a  concern  that  a  Web-based  navigation-planning 
tool  would  not  be  available  to  them  because  they  do  not  currently  possess  the  needed 
telephone  lines,  personal  computers,  or  network  access  necessary  to  support  such  a  tool 
(Appendix  E).  Fortunately,  the  move  to  bring  the  Internet  and  more  networked  computer 
resources  to  sea  has  begun,  as  evidenced  by  initiatives  such  as  SeaNet,  IT-21,  and  ADNS, 
among  others.  The  newest  surface  ship  classes  such  as  the  DDG-51  and  LHD-1  are  being 
built  with  high  capacity  computer  networks,  although  this  does  not  solve  the  submarine’s 
connectivity  problem  while  submerged.  This  may  be  the  strongest  argument  yet  to 
design  any  navigation  migration  system  so  that  all  needed  data  and  software  is  contained 
onboard  (locally),  such  as  with  the  CD  jukebox  method.  Periodic  updates  could  still  be 
sent  via  an  outside  network,  which  a  submarine  could  access  for  updates  when  it  is 
surfaced. 

D.  SUMMARY 

A  significant  benefit  of  using  network  technology  in  conjimction  with  databases 
and  other  incompatible  data  formats  is  that  a  common  interface  can  be  achieved  for 
multiple  heterogeneous  platforms  [Ref.  25].  This  is  the  beauty  of  such  an  arrangement: 
Vast  quantities  of  distributed  information  can  be  “pulled”  by  a  user  into  a  single,  easy  to 
use  Web  interface.  The  benefits  of  using  Web  and  database  technology  can  be 
summarized  as  follows: 

The  recent  popularity  of  the  World  Wide  Web  has  created  a  massive 
increase  in  both  the  supply  and  demand  of  Web-based  technologies. 
However,  the  HyperText  Markup  Language  used  to  construct  the  Web  has 
limitations  that  challenge  information  content  providers  who  want  to 
supply  current,  up-to-date  information  with  minimal  administrative 
overhead.  A  powerful,  extensible  solution  to  many  of  these  challenges  is 
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the  use  of  a  database  as  a  back  end,  or  data  source,  for  Web  applications. 
Combining  the  Web  with  a  database  maximizes  the  strengths  of  its 
components.  From  the  Web  perspective,  this  combination  offers  user 
friendliness,  cross-platform  compatibility,  and  high-speed  prototyping 
capabilities.  From  the  database  perspective,  it  offers  relational  data 
manipulation,  high-speed  search  capabilities,  and  industrial  grade  data 
input  and  retrieval  [Ref  26]. 

This  migration  path  was  chosen  for  the  GatorNet  prototype  development. 
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IV. 


“GATORNET”  RAPID  PROTOTYPE 


In  order  to  prove  the  “GatorNet”  concept,  a  rapid  prototype  was  developed  to 
demonstrate  functionality  and  design  possibilities.  Although  the  World  Wide  Web 
(WWW)  may  not  be  the  medium  of  choice  for  the  final  product,  it  allowed  a  convenient 
means  to  provide  quick  exposure  of  the  prototype  to  decision-makers  and  achieve 
widespread  visibility  with  Navigators  throughout  the  Navy.  The  WWW  also  provides  the 
perfect  forum  to  easily  distribute  the  prototype  to  widely  disbursed  clients  and  gather 
feedback  for  improvement.  With  these  benefits  in  mind,  a  web  based  application  was 
chosen  for  the  prototype  with  the  understanding  that  distributed  CD-ROMs  may  prove 
more  cost  effective  for  the  actual  system  until  bcindwidth,  security,  connectivity  and 
standardization  issues  are  resolved.  These  issues  will  be  addressed  in  the  following 
chapter. 

A.  PROTOTYPE  OVERVIEW  AND  GOALS 

Several  areas  were  identified  from  the  fleet  survey  as  being  candidates  for  proof 
of  concept  within  the  prototype.  To  manage  the  scope  of  the  prototype,  three  primary 
areas  were  chosen.  The  first  was  visually  depicting  aids  to  navigation  and  harbors  since  it 
exploits  a  new  concept  that  does  not  readily  and  widely  exist  in  current  planning.  The 
second  was  developing  a  Navigation  Lessons  Learned  Database  that  allows  quick  and 
easy  access  with  more  functionality  than  the  existing  NTIC  CD-ROM  or  Port  Directory 
publication  systems.  The  third  was  creating  port  specific  web  pages  that  can  be  used  to 
gather  and  disseminate  timely  information.  To  educate  the  user  on  the  purpose  behind 
“GatorNet”,  survey  results  and  thesis  chapters  were  made  accessible  on  the  prototype  site. 
Links  to  other  navigation  related  sites  were  also  included. 

San  Diego,  California  was  chosen  as  the  primary  harbor  for  data  collection.  As 
the  largest  naval  homeport  on  the  West  Coast,  it  provides  a  familiar  example  to  a  large 
number  of  potential  users.  San  Diego  also  provides  a  rich  number  of  aids  to  navigation. 
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The  true  value  of  “GatorNet”,  however,  is  providing  a  wealth  of  information  on  a  port 
not  yet  visited  by  the  navigator. 

1.  Visual  Depiction  of  Navigation  Aids  and  Harbors 

With  the  advent  of  Differential  Global  Positioning  Systems  (DGPS)  on  each  coast 
of  the  United  States,  an  argument  could  be  made  that  the  accuracy  of  this  system  (within 
meters)  will  one  day  make  traditional  visual  navigation  procedures  (triangulation  through 
lines  of  position)  obsolete.  With  less  than  100  percent  reliability  and  less  than  total 
coverage  throughout  the  world’s  harbors,  that  day  is  well  into  the  future.  Given  that 
visual  navigation  will  be  required  to  guarantee  the  safety  of  our  ships,  it  stands  to  reason 
that  a  better  prepared  navigation  team  is  less  likely  to  hazard  the  ship  and  its  crew. 
Preparation  can  come  in  many  forms.  Historically,  the  navigation  team  researches 
restricted  water  transits  in  publications  such  as  the  Port  Directory,  Sailing  Directions 
(foreign  ports).  Coast  Pilots  (US  ports),  Fleet  Guides  (approximately  15  highly  visited 
Naval  Ports),  and  through  pertinent  message  traffic. 

Several  of  the  publications  contain  aerial  photographs  for  the  larger  ports  to  give 
an  overview  of  the  harbor  layout.  Occasionally  they  depict  a  primary  navigation  aid  such 
as  range  markers  to  the  main  channel  or  a  lighthouse.  A  thorough  repository  that  includes 
pictures  of  multiple  navigation  aids  that  have  been  successfully  used  by  other  ships  would 
allow  the  team  to  better  plan  and  preview  their  transit.  In  addition,  comments  by 
navigators  on  aids  that  may  appear  useful  on  a  chart  yet  are  difficult  to  acquire  could 
greatly  assist  the  team.  Imagine  having  a  brand  new  seaman  shooting  lines  of  position 
for  a  Commanding  Officer  and  Navigator’s  first  visit  into  the  busy  port  of  Hong  Kong. 
The  chance  of  locating  and  providing  a  timely  bearing  are  increased  tremendously  if  that 
seaman  has  a  chance  to  view  photos  of  the  navigation  aids  prior  to  making  the  transit. 

Still  pictures  were  chosen  for  the  prototype  due  to  storage  and  bandwidth 
considerations.  Several  pixel  dimension  and  JPEG  compression  factor  combinations  were 
experimented  with  to  produce  a  good  quality  picture  while  minimizing  file  size.  The 
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primary  goal  was  to  keep  the  file  size  tolSKb  to  minimize  user  download  time.  With  a 
JPEG  quality  factor  of  100  (Corel  Photo-Paint’s  scale  ranges  from  2-High  to  255-Low), 
the  color  pictures  used  throughout  the  prototype  averaged  10- 15Kb  (image  size 
approximately  3x5  inches  on  screen  with  800  x  600  resolution).  Several  pictures  were 
cropped  with  smaller  dimensions  depending  on  the  navigation  aid’s  size  and 
characteristics  to  further  reduce  file  size.  The  pictures  were  taken  with  a  35mm  camera, 
scanned  into  Corel  Photo-Paint  and  sharpened  ten  percent  to  show  greater  detail.  When 
developing  the  web  pages,  keeping  the  total  page  size  less  than  20K  resulted  in  a 
reasonable  page  transfer  time  of  less  than  ten  seconds  given  a  meager  2K/sec-transfer  rate 
that  is  typically  experienced  through  a  remote  access  modem  connection.  If  the  ultimate 
GatorNet  product  were  to  include  archives  of  photographs  on  a  periodically  distributed 
CD-ROM,  larger  and  higher  quality  pictures  could  be  included.  Pictures  available 
“online”  could  be  limited  to  urgent  ones  dealing  with  safety  issues,  corrections  to  existing 
pictures,  or  those  that  are  deemed  crucial  and  add  significant  clarity  to  a  confusing 
navigation  aid. 


2.  Lessons  Learned 

As  evidenced  in  the  survey  results,  only  36%  of  the  commands  surveyed  maintain 
organized  lessons  learned  files  on  port  visits.  With  a  navigator  holding  the  position 
usually  less  than  two  years,  there  is  considerable  “corporate  knowledge”  that  is  lost.  By 
improving  the  method  for  collection  and  increasing  the  repository  of  information 
available  to  the  navigation  team,  this  knowledge  can  be  captured  and  overall  safety 
improved. 

In  designing  the  GatorNet  lessons  learned  applications,  the  following 
improvements  were  desired: 

•  Increased  volume  of  lessons 

•  Quicker  turnaround  of  information  and  easier  access 

•  Capturing  author  information  and  establishing  a  user  database  to  enable 
contact  through  e-mail  for  future  amplification  should  users  have  questions 
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•  Quantitative  orientation  to  provide  precise,  measurable  data  points  for  users 

•  Graphic  orientation  and  the  ability  to  correlate  lessons  with  photographs 

Searching  the  entire  unclassified  October  1997  NTIC  Series  A  CD-ROM  yields 

less  than  ten  robust  port  visit  lessons  dating  back  through  early  1996.  The  NLLS  Fleet 
Management  Sites  (FLTCINCS,  CINCUSNAVEUR,  and  COMUSNAVCENT)  validate 
new  lessons  and  review  the  database  for  currency  and  adequacy.  Lessons  are 
automatically  expunged  from  the  database  after  two  years  imless  revalidated  by  the 
Management  Site.  Several  smaller  ports  are  not  visited  with  great  frequency,  and 
although  desired,  ships  are  not  always  required  to  submit  a  lesson  learned.  Due  to  Secret 
classifications,  the  NTIC  CD-ROMS  usually  reside  within  the  Intelligence  spaces  on  a 
ship  and  are  not  easily  quickly  accessible  by  the  standard  user.  This  combination 
produces  the  sparse  number  of  navigation  lessons  present  in  the  current  system.  Survey 
results  demonstrated  that  the  system  is  a  complete  failure  with  respect  to  navigation  (47% 
of  respondents  had  never  used  the  system  and  36%  use  it  less  than  once  a  month). 

The  Port  Directory  contains  reports  from  ships  on  virtually  every  port  visited  by 
naval  ships,  but  many  are  very  dated  and  the  reports  are  exclusively  text  oriented.  Ships 
are  periodically  tasked  to  provide  a  report  to  update  the  directory.  The  reports  are 
cumbersome  and  require  inputs  from  several  departments  throughout  the  ship.  Typically 
no  feedback  is  received  and  new  reports  are  not  incorporated  until  the  annual  update.  By 
providing  users  standardized  forms  (GatorNet  uses  a  modified  and  scaled  down  version 
of  the  submission  form  for  the  Port  Directory)  that  are  simple  to  complete,  the  concept  is 
to  capture  as  many  value  added  lessons  possible  after  each  evolution.  Keeping  the 
process  simple  increases  participation.  This  can  be  accomplished  if  a  Navigator  can  sit 
down  at  a  readily  available  personal  computer,  quickly  fill  out  pertinent  comments,  attach 
a  picture  if  necessary  from  a  digital  camera  to  clarify  the  situation,  and  electronically 
submit  a  completed  form.  Building  a  robust  repository  where  contributors  can  quickly 
see  the  fruits  of  their  effort  and  benefit  from  other  users  is  the  key  to  a  successful  system. 
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3. 


Port  Data 


There  are  several  areas  of  interest  in  addition  to  navigation  for  ships  preparing  to 
enter  port.  Much  of  the  time  sensitive  and  ship  dependent  information  is  supplied 
through  message  traffic  in  reply  to  the  logistics  request  (LOGREQ)  message  sent  before 
entering  port.  Searching  the  WWW  for  information  on  world  ports  yields  considerable 
information  in  a  variety  of  formats.  The  intention  behind  this  portion  of  GatorNet  was  to 
show  the  functionality  that  could  be  achieved  through  simple,  static  web  pages.  Area 
commanders  could  use  these  web  pages  to  disseminate  pertinent  information  and  provide 
guidance  to  ships  preparing  to  enter  port.  The  potential  use  is  unlimited  and  could  range 
from  pertinent  instructions  or  regulations,  a  calendar  of  events,  schedules  for  opareas, 
weather  forecasts,  or  points  of  contact. 

B.  PROTOTYPE  FUNCTIONALITY 

The  prototype  is  designed  to  be  as  user-friendly  and  as  self-explanatory  as 
possible.  On-screen  examples  are  provided  for  clarity,  and  help  buttons  are  available  if 
necessary.  Image  icons,  point  and  click  maps,  and  drop  down  lists  were  used  extensively 
to  provide  the  inexperienced  web  user  a  simple  interface. 

1.  “GatorNet”  Homepage 

The  GatorNet  homepage  is  displayed  in  Figure  4-1.  It  provides  links  to  the  major 
areas  of  the  prototype  mentioned  previously.  It  also  provides  the  user  with  a  statement  on 
the  purpose  behind  the  prototype  and  who  to  contact  if  there  are  questions. 

2.  Ports 

Selecting  the  Ports  Icon  presents  the  user  with  a  world  map  for  the  user  to  view 
and  select  a  port.  After  selecting  the  Southwestern  United  States,  the  user  can  gain  access 
to  the  prototype  site  of  San  Diego.  Figure  4-2  contains  the  San  Diego  harbor  navigation 
frame  presented  to  the  user.  The  Ports  section  of  the  prototype  is  one  of  the  primary 
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methods  of  accessing  pictures  of  navigation  aids.  For  the  prototype,  sections  of  charts 
18765  and  18773  were  scanned  to  assist  the  user  in  correlating  pictures  with  aids. 


(5atorNet 

The  Navigator's  Planning  Network 


Fleet  Survey 
Results 


Lessons  Leorned 
Database 


Nav  Links 


Thesis 


Ports  I  Lessons  Learned  Database  |  Survey  Results  |  Thesis  |  Navigation  Hot  Links 

About  GatorNet... 

GatorKet  is  a  prototype  site  to  enhance  feedback  and  improve  planning  for  Navigators  of  all  flavors.  There  are  a 
finite  number  of  ports  on  earth,  and  navigators  have  traversed  their  waters  for  many  years.  Modem  navigation 
tools  like  GPS  assist  in  open  water  navigation,  but  only  serve  a  backup  role  for  large  ships  during  restricted 
channel  and  harbor  transits.  Differential  GPS  improves  on  GPS*  accuracy  but  is  still  not  widely  available.  Visuai 
navigation  is  (and  will  be  for  quite  some  time)  the  primary  tool  for  safely  passing  through  restricted  waters. 


F  igure  4- 1 .  “GatorNet”  Homepage 

San  Diego  is  a  lengthy  harbor  transit,  and  to  maintain  enough  detail  yet  minimize 
download  time  it  was  necessary  to  create  several  web  pages  containing  portions  of  the 
transit.  By  selecting  an  outlined  portion  of  the  channel,  the  user  is  presented  with  Figure 
4-3.  Aids  that  have  pictures  associated  with  them  are  highlighted  and  contain  a  link  to  an 
additional  web  page  as  depicted  in  Figure  4-4.  If  necessary,  the  pictures  can  be  annotated 
before  posting  to  clarify  the  actual  navigation  aid,  describe  where  the  picture  was  taken 
from,  or  present  photographer  comments.  A  user  with  an  actual  harbor  chart  can  easily 
correlate  the  digital  image  to  the  actual  chart.  As  photos  are  submitted,  it  is  a  fairly 
straightforward  task  for  the  administrator  to  highlight  the  chart  and  create  new  links. 


SanDiegoFfame  -  MictosofI  Internet  Expli 


San  Diego 
California 

Had)or  Navigation 

Home  Port 

Publications 

Weather 

Safety 

Commercial  Info 

Operations 
Return  to  Homepage 


Figure  4-2.  San  Diego  Home  Page 
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The  remainder  of  the  icons  on  the  Ports  web  page  can  be  structured  to  contain 
pertinent  information.  Home  Port  could  contain  information  from  the  area  commander, 
links  to  local  command  web  sites,  or  training  information.  Publications  might  contain 
downloadable  Portable  Document  Format  (PDF)  documents  such  as  Fleet  Guides, 
portions  of  navigation  publications  (Sailing  Directions  or  Coast  Pilots)  pertinent  to  that 
port,  or  other  relevant  instructions  or  regulations.  For  the  San  Diego  prototype.  Weather 
contains  HTTP  links  to  local  area  forecasts  and  tide  information.  The  final  product  could 
contain  a  tide  and  current  program,  links  to  weather  forecasts,  sea-state  observations  or 
sunrise/simset  computations. 
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Safety  could  contain  Local  Notices  to  Mariners,  pertinent  Hydropacs  or 
Hydrolants,  phone  numbers  for  oil  spill  response  teams,  or  local  mishap  procedures  and 
phone  numbers.  Commercial  Information  may  show  local  street  maps,  phone  numbers 
for  tug  or  pilot  services,  provide  entertainment  or  restaurant  recommendations,  or 
instructions  on  water  and  waste  services.  Operations  is  an  area  that  could  list  schedules 
for  exercises,  communications,  or  training  information.  The  ultimate  design  is  only 
limited  by  the  imagination. 
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Figure  4-4.  Ballast  Point  Navigation  Aid 


3.  Lessons  Learned 

As  the  user  clicks  the  lessons  learned  icon  on  the  GatorNet  home  page,  Figure  4-5 
is  displayed.  Although  named  a  “lessons  learned  database”,  it  is  a  relational  database 
containing  users,  navigation  aids,  photographs,  comments  and  voyage  lessons.  The  rapid 
prototype  contains  five  applications  (CGI  scripts)  for  querying  Units,  Lessons  Learned, 
Photographs,  Photograph  Comments,  and  Navaids.  It  also  contains  three  applications  for 
Voyage  Entry,  Photo  Submission,  and  Photo  Comments.  The  user  accesses  these  query 
forms  by  pressing  the  appropriate  button. 
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Navigation  Lessons  Learned  Database 


The  prototype  database  contains  information  concerning  ships^  voyages  (harbor  transits^  straits  transits, 
etc.),  navaids,  and  photographs.  The  database  is  a  '^slimmed  down''  version  of  the  extensive  relational 
database  that  would  be  required  to  truly  contain  die  enormous  amounts  of  data  for  navigation  planning 
(hit  "Schematic"  link  below  to  see  how  database  is  accessed).  To  demonstrate  the  functionality  of 
accessing  or  entering  navigation  data  and  the  types  of  queries  that  can  be  performed,  choose  a  link  below. 


Lesson  Learned 


Submit  Photograph 


View  Database  Schematic 


Lessons  Learned  Search  |  Photo  Search  |  Navaid  Search  |  Unit  Search 
Submit  Lesson  |  Submit  Photo  |  Comments  |  Help  |  View  Database  Schematic 


’  Return  to  Homepage 


Figure  4-5.  Lessons  Learned  Main  Page 


Since  the  only  photographs  currently  populating  the  prototype  database  contain 
navigation  aids,  both  the  Navaid  and  Photograph  Search  buttons  display  Figure  4-6. 


feotorNe;,  Navaid  Query 


NavAid  Name: 
Chart  Number: 


Type  of  Navaid:  ^ 

Rnd  I  Reset  Values  I 


Figure  4-6.  Navaid  Search 
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In  the  final  product,  pictures  of  tugs,  piers,  fittings,  or  even  equipment  like  brows 
or  cranes  could  populate  the  database.  Figure  4-7  illustrates  the  query  form  for  a 
“Lessons  Learned  Search”.  All  query  forms  have  a  similar  look  and  feel.  If  left  blank,  all 
records  will  be  displayed.  To  narrow  the  search  standard  operators  (>,=,<,  contains, 
begins  with,  etc.)  can  be  used  for  matching.  Once  the  “Find”  button  is  selected,  matching 
records  are  returned  as  in  Figure  4-8.  The  user  can  “drill  down”  to  gain  amplifying 
information  as  in  Figure  4-9  by  selecting  the  hyperlink  field. 

To  minimize  response  time,  the  picture  is  a  selectable  button.  A  user  can  provide 
comments  on  the  picture  if  deemed  necessary  as  in  Figure  4-10.  This  allows  a 
mechanism  for  feedback  and  allows  future  users  to  gain  more  confidence  that  the  picture 
they  are  viewing  is  in  fact  the  proper  navigation  aid.  A  radio  button  scale  fi-om  one 
through  five  is  provided  when  submitting  pictures  or  when  commenting  on  pictures. 
Since  an  inaecurate  picture  could  be  a  potential  safety  hazard  (misinformation  could  be 
more  detrimental  than  no  information  at  all),  this  confidence  ranking  system  and  the 
ability  to  provide  additional  comments  are  two  methods  to  mitigate  potential  problems. 


Voyage  Query 


Event  Date: 

Countiy: 

Chart  Number: 

Hull  Number: 

Ship  Class:  |BeginsWM^^ 


E 


Voyage  Name:  jcortains  ||J 

1  ResetVrfuwsj  Leave  AH  fields  blank  to  see  all  lessons. 


Figiue  4-7.  Lessons  Learned  Search 
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When  submitting  either  a  lesson  (voyage,  harbor  transit,  anchorage,  exercise,  etc.), 
photograph  or  comment  into  the  database,  the  records  are  added  to  a  temporary  database 
where  the  administrator  can  sanitize  the  information.  Although  an  extra  step  for  the 
administrator  to  validate  and  transfer  records  to  the  master  database,  this  provides  a 
measure  of  security  against  user  mistakes,  intentional  misinformation  or  spoofing,  or  poor 
entries.  An  Access  ‘97  macro  could  easily  be  written  to  transfer  validated  records  and 
append  the  master  database.  All  queries  access  the  master  database  that  contains  the 
sanitized  information. 

Figure  4-11  contains  an  example  of  the  Photo  Submission  Form.  The  same  user 
information  is  collected  when  entering  a  photograph,  lesson  or  comment.  By  collecting  the 
phone  number,  point  of  contact,  and  e-mail  address,  a  fijture  user  should  be  able  to 
quickly  contact  the  originator  should  there  be  questions.  With  the  proliferation  of  e-mail, 
the  day  when  service  members  can  easily  be  located  even  after  transferring  to  new 
commands  is  at  hand.  This  added  feedback  mechanism  is  invaluable,  and  would  have 
widespread  application  beyond  navigation. 

Pictures  can  be  related  to  specific  voyages  or  can  be  entered  independently.  When 
entering  voyage  information,  a  voyage  identification  number  (the  database  table  primary 
key)  is  provided  to  the  user  for  reference  when  submitting  photographs  (9999  is  used  as 
the  default  if  the  photograph  is  submitted  independently).  After  submitting  a  photograph, 
a  photo  identification  number  is  provided  for  annotating  on  the  back  of  a  mailed 
photograph  or  attaching  to  an  electronically  submitted  photograph.  These  measures 
provide  the  database  administrator  with  a  mechanism  to  keep  voyages,  photographs  and 
data  records  correlated. 
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Q,atorNe^  Matching  Navaids 


There  are  9  matching  records.  Displaying  matches  1  throu^  9. 


Chart  Number 

NavAidName 

Type  of  Navaid 

18773 

PT  Loma  Lishthouse 

Li^thouse 

118773 

Ballast  Pt.  Lisht 

Light 

1 18773 

i 

Old  Lighthouse 

Lighdiouse 

1 18773 

"Z"  Light 

Light 

18773 

Entrance  Range  Front 

Li^t 

18773 

Shelter  Island  "S” 

Light 

[18773 

North  Island  "4" 

Li^t 

18773 

N.Island'N”  Light 

Light 

18773 

N.  Island  Aerobeacon 

Light 

Figure  4-8.  Matching  Record  Form  for  Navaid  Search 


Figure  4-12  shows  the  initial  portion  of  the  details  from  a  sample  voyage  entry. 
Other  pertinent  navigation  information  such  as  visual  navigation,  radar  navigation,  tug, 
tides/currents,  depth  and  many  other  areas  are  collected  on  the  voyage  entry  form.  If  a 
field  is  left  blank  during  record  submission,  the  field  is  not  displayed  when  querying. 
Memo  field  data  types  are  used  to  store  comment  information  and  minimize  the  size  of 
the  database.  Only  the  amoimt  of  information  typed  in  by  the  user  is  stored  and  not  a 
fixed  record  size. 
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Navaid  Details 

NavAid  Name: 

Entrance  Range  Front 

Type  of  Navaid: 

Light 

Chart  Numben 

18773 

Lat/Long: 

3242.3N11714.0W 

PubDescriptioti: 

L.  List:  No.  1 500;  Front  Range  Q  G,  22  ft,  KRW  on  white  column; 

KRW  on  skeleton  tower,  visible  4  deg  each  side  of  rangeline 

Click  for  picture 

Coirmief^onPi^ 

ViewvMCofm^^ 

Figure  4-9.  Matching  Record  Detail 
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Photo  Comments 


Hull  Number: 
Ship  Class; 
E-Mail  Address: 
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iDSNGSe-IOIS 


Unit  Point  Of  Contact  |K«tl  Thomas 

ExtraComments:  Once  established  on  the  356  leg, 
channel  buoys  can  be  used  to  help 
bcale  the  range.  Range  is  typically  — 
visible  to  the  nakefcl  eye  before  the 

Confidence:  Low  rir2r3r4<5^  5S^ 
Sava  I  Reset  Values  I 
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Qjctor/Sie/  Photo  Submission 

HuB  Number:  j 

(lELPH-ll) 

Ship  Class:  [ad 

E-Mail  Address:  | 

Phone:  j 

Unit  Point  Of  Contact:  j 

Chart  Nvimbcr  ] 

Voyage  Number  9999  :  (Change  only  if  assigned  a  new  number  when  enterring  Voyage  feedback  form) 

Lat/Long:  | 

aE3252.3N11714.2W) 

NavAidName:  | 

Type  ofNavaid:  |Light 

i 

Date  Picture  Taken: 

^  (Must  enter  numbers  or  will  receive  an  error!) 

Photographer's  Comments: 

.d 

Confidence  Level:  Low 

. zJ 

C  1  r  2  r  3  r4  r  SHigh 

(How  confident  are  you  the  picture  is  the  Navaid  specified?) 

Figure  4-11.  Photo  Submission  Form 


Voyage  Details 

Event  Date: 

970508 

Chart  Niimben 

21338 

Hull  Number: 

PC-8 

Voyage  Name: 

Puerto  Vallarta  Port  Visit 

Country: 

Mexico 

Lat/Long: 

2039N10515'W 

FSot  Ranking:: 

9 

Hlot 

Comments; 

PHOT  IS  COMPTXLSORY,  PILOT  IS  REACHED  VIA  BB  CH 16  “CAPHANIA,  PUERTO 
VALLARTA."  TRANSLATES  TO  “HARBOR  MASTER,  PUERTO  VALLARTA."  PILOTS  SPEAK 
ENGLISH  PILOT  BOARDED  1  MILE  SOUTH  OF  BREAKWAIHl 

Figure  4-12.  Lesson  Learned  Search  Result 
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4.  Survey  and  Thesis  Results 

In  order  to  disseminate  the  large  volume  of  information  collected  in  the  fleet 
survey,  the  results  are  posted  on  the  GatorNet  prototype.  Links  are  provided  to  the 
graphical  and  tabular  results  of  Chapter  II  and  the  Appendices.  The  narrative  comments 
listed  in  Appendix  E  are  also  provided.  Users  viewing  the  survey  information  are  free  to 
make  comments,  adding  to  the  feedback  available  to  future  GatorNet  developers.  The 
“thesis  results”  section  of  the  prototype  contains  an  HTML  version  of  this  document 
accessible  by  chapter. 

5.  Navigation  Links 

While  conducting  research  and  developing  the  GatorNet  prototype,  several  useful 
web  sites  were  discovered.  These  sites  are  organized  on  the  Nav  Links  page.  This  could 
be  an  expanding  and  evolving  page  containing  links  to  ports,  users,  navigation  products, 
navigation  research  and  development  projects,  or  anything  else  pertinent  to  navigation. 

C.  SEMANTIC  OBJECT  MODEL 

When  designing  the  database  structure  to  contain  the  repository  of  information  for 
the  prototype,  the  semantic  object  model  was  chosen  over  the  entity  relationship  model. 
Semantic  Object  modeling  is  particularly  well  suited  for  the  bottom-up  development 
approach  taken  toward  the  rapid  prototype  [Ref  27:p.47].  This  choice  was  also  made  due 
to  the  availability  of  and  familiarity  with  the  SALSA  schema  generation  software. 

The  initial  database  structure  was  a  vast,  all  encompassing  effort  to  design  a 
database  that  could  accommodate  a  full-scale  GatorNet  implementation.  Approximately 
15  objects  were  used  and  included  navaids,  charts,  ports,  piers,  pilots,  hazards,  individual 
users,  and  units  to  name  a  few.  Several  of  these  objects  had  group  attributes  and 
attributes  with  maximum  cardinalities  of  “N”.  Once  the  schema  was  generated,  well  over 
30  tables  existed.  Schema  generation  was  not  difficult,  but  as  applications  were 
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developed  to  access  the  relational  tables  it  quickly  became  apparent  that  a  greatly  scaled 
down  version  would  be  needed  to  manage  the  scope  of  these  applications  and  complete 
the  rapid  prototype. 

When  using  relational  tables,  foreign  key  management  becomes  critical.  As  the 
number  of  objects  and  relations  increase,  the  application  development  becomes 
increasingly  difficult.  The  other  extreme  is  to  use  a  flat  file  scheme,  but  this  results  in 
considerable  data  redundancy.  Figure  4-13  contains  the  five  objects  used  within  the 
prototype  and  their  associated  data  attributes.  These  objects  provided  ample  information 
to  prove  the  GatorNet  concept. 
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Figure  4-13.  Database  Objects  and  Relations 


D.  RELATIONAL  DATABASE 


Access  ’97  was  used  for  the  relational  database  software  for  several  reasons.  The 
primary  reason  was  familiarity  and  availability  of  the  software  package.  Additionally, 
since  Microsoft  Office  ’97  has  been  mandated  as  the  standard  for  IT-21  [Ref  13],  it  made 


sense  to  use  a  software  package  that  will  be  widely  available  throughout  the  fleet. 
Furthermore,  since  Front  Page  was  the  web  development  software  and  Microsoft  Internet 
Information  Server  (IIS)  the  web  server,  using  solely  Microsoft  products  decreased 
chances  for  incompatibility. 

To  minimize  complexity,  auto-generated  primary  key  integers  were  used  for  each 
object.  Prior  to  each  new  record  entry,  a  direct  DBMS  action  is  performed  by  the  Tango 
middleware  (discussed  later  in  the  chapter)  to  determine  the  last  record  in  a  table.  The  ID 
is  incremented  by  one  and  a  new  record  created. 

1.  Unit  Table 

In  the  prototype,  every  time  a  user  enters  information  for  a  new  photograph, 
comment  or  voyage  a  record  is  added  to  the  Unit  table.  This  creates  obvious  data 
redundancy.  In  the  final  product,  a  password  and  user-ID  scheme  would  end  this 
drawback  and  keep  the  administrator  from  having  to  purge  the  Unit  table  of  duplicate 
records  while  correcting  the  unit  foreign  keys  within  other  tables. 

Both  Hull  Number  and  Ship  Class  attributes  exist  to  allow  searches  on  either  item. 
A  more  robust  system  would  accommodate  staffs  and  individual  users.  A  unit  can  be 
related  to  multiple  photographs,  comments,  or  voyages.  Therefore,  the  foreign  key  of  the 
unit  resides  in  those  tables. 

2.  Photograph  Table 

The  photograph  table  is  straightforward.  The  Confidence  attribute  stores  a  1-5 
value  assigned  by  the  photographer  rating  how  sure  that  particular  picture  shows  the 
actual  navaid.  This  allows  a  degree  of  reliance  to  be  placed  in  pictures  by  navigators 
using  the  system.  The  Image  Hyperlink  contains  a  hyperlink  to  the  JPEG  filename.  The 
Image  Transfer  attribute  is  not  functional,  but  was  designed  to  store  a  binary  value 
depending  if  the  image  was  electronically  submitted  or  mailed  to  the  database 

administrator.  The  foreign  key  for  Navaid  is  in  the  Photograph  table  since  a  navaid 

conceivable  could  have  more  than  one  picture  submitted. 
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3.  Voyage  Table 

The  attributes  contained  in  the  Voyage  table  allow  a  basic  lesson  learned  format 
geared  toward  a  restricted  water  transit.  The  multiple  Comments  attributes  use  the  memo 
field  and  allow  text  based  discussion.  The  Ranking  attributes  contain  an  integer  between 
1-5  as  selected  by  the  user  with  a  radio  button.  This  ranking  mechanism  could  be  used  to 
collect  opinions  over  time  and  develop  statistical  data  on  tugs,  pilots,  visual  and  radar 
navigation  aids.  This  would  provide  yet  one  more  feedback  mechanism  for  a  navigator 
during  preparation. 

4.  Navaid  Table 

The  Type  attribute  is  a  drop  down  list  to  categorize  navigation  aids  (light, 
lighthouse,  buoy,  structure,  building  etc.)  and  assist  in  queries.  The  Image  File  Name 
attribute  stores  the  JPEG  filename.  Pub  Description  includes  information  that  is  fovmd  in 
the  various  planning  publications  as  a  way  of  consolidating  information  into  one  easy 
access  location.  Photo  Avg.  stores  the  average  value  computed  from  the  photographer’s 
and  other  user’s  confidence  entries. 

5.  Comments  Table 

This  table  captures  comments  made  by  users  when  viewing  pictures  already  in  the 
database.  Units  can  make  multiple  comments,  and  photographs  can  have  multiple 
comments  made  on  them  so  both  of  these  foreign  keys  reside  in  this  table.  The  date  is 
automatically  entered  when  the  user  submits  the  comment. 

6.  Navaid  Voyage  Table 

This  table  is  required  since  voyages  can  contain  multiple  navaids,  and  a  navaid 
can  be  associated  with  more  than  one  voyage.  Both  foreign  keys  are  contained  within  the 
table  to  relate  the  two  objects. 
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E.  TANGO  FOR  ACCESS 


In  order  to  assist  in  developing  applications  to  access  the  database  through  the 
GatorNet  web  site,  we  chose  Every  Ware  Development  Corporation’s  Tango  product. 
This  product  provides  a  straightforward  method  to  create  basic  query  documents  for 
accessing  a  relational  database  and  formatting  returned  results.  When  searching  for 
information  from  more  than  one  table,  the  software  allows  the  user  to  define  joins. 
Creating  applications  to  enter  new  records  into  a  single  table  within  the  database  is 
accomplished  by  using  the  New  Record  Query  Builder  function  in  the  software. 
Expanding  the  functionality  to  enter  data  into  related  tables  is  accomplished  by  creating 
query  documents  for  each  table,  and  combining  them  by  cutting  and  pasting  the  HTML 
code.  SQL  statements  were  used  to  increment  primary  keys  and  ensure  foreign  keys  were 
entered  into  appropriate  tables.  Very  little  altering  of  the  Tango-generated  forms  was 
necessary  to  obtain  the  figures  shown  throughout  this  chapter.  Although  not  entirely 
point  and  click.  Tango  for  Access  greatly  reduced  the  CGI  coding  requirements  to 
achieve  database  interaction. 

The  Tango  Server  executes  the  requested  query  documents,  performs  the 
operations  defined  in  the  document,  communicates  with  the  database,  and  returns  the 
results  to  the  IIS  server  to  be  passed  on  to  the  user.  A  plug-in  is  provided  for  Microsoft’s 
IIS  to  speed  up  the  passing  of  information  between  the  two  servers.  An  application  was 
required  for  each  of  the  functions  outlined  in  the  previous  Lessons  Learned  section  of  this 
chapter. 

F.  WEB  INTERFACE  DEVELOPMENT 

Front  Page  ’97  was  chosen  for  developing  the  GatorNet  site.  The  primary  reasons 
behind  choosing  this  software  package  was  availability  and  the  compatibility  with 
Microsoft  IIS,  Access  97,  and  the  Windows  NT  operating  system.  The  structures  for 
several  web  pages  within  the  prototype  were  created  using  wizards  available  within  the 
software.  No  significant  problems  were  encountered  during  development  or  publishing. 
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G.  PROTOTYPE  HARDWARE/SOFTWARE  REQUIREMENTS  AND  COSTS 

The  prototype  was  developed  on  a  200MHZ  Intel  Pentium  personal  computer 
with  32Mb  of  RAM.  Pictures  were  taken  with  a  personal  35mm  camera  using  an  80- 
210mm  zoom  lens.  Images  were  scarmed  into  the  prototype  using  a  HP  ScanJet  4P 
scanner.  No  other  special  hardware  was  purchased  or  required.  No  special  software  or 
hardware  was  required  so  costs  were  truly  kept  to  a  minimum. 

The  following  software  was  used  to  develop  the  prototype: 

•  Microsoft  Office  97  (Word,  Excel,  Access) 

•  Corel  Photo-Paint  5.0 

•  Frontpage  97 

•  Tango  for  Access 

•  Salsa  Academic  Edition  for  Students  V  1 . 1 

•  Microsoft  IIS 

•  Microsoft  Internet  Explorer  and  Netscape  Communicator 

•  Windows  NT  4.0 

All  software  except  Tango  for  Access  was  either  already  owned  by  the  authors  or 
available  on  the  NPS  personal  computer  used  to  develop  the  prototype.  Tango’s 
educational  version  cost  under  $150.  As  a  benchmark  for  other  rapid  prototype 
developers,  it  is  estimated  that  the  suite  of  hardware  and  software  used  to  develop  and 
serve  the  prototype  cost  under  $4,000.  A  full-scale  implementation  of  the  GatorNet 
concept  would  require  much  greater  redundancy,  speed,  reliability  and  security  and 
consequently  be  more  expensive. 

The  site  is  served  fi'om  the  same  personeil  computer  used  to  develop  the  protot5q)e. 
The  computer  is  connected  to  a  lOMBPS-Ethemet  network  at  the  Naval  Postgraduate 
School  and  is  accessible  at  http://pci cml  .ece.nps.navv.mil/Gatorhome.htm. 
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V. 


FLEET  IMPLEMENTATION  OF  A  NEW  NAVIGATION  PLANNING 
SYSTEM  AND  ASSOCIATED  INTEGRATION  ISSUES 


A  high  visibility  and  priority  item  in  fleet  navigation  today  is  the  program  to 
finally  transition  from  paper  to  digital  nautical  charts  (DNC).  The  Eiectronic  Chart 
Display  and  Information  System  (ECDIS)  would  accomplish  this  and  be  based  on 
commercial  standards  that  have  extensions  for  military  applications.  Navigation  sensors 
(such  as  GPS/DGPS/Inertial  Gyros)  will  provide  inputs  to  the  system  to  allow  positional 
display  and  assist  in  route  planning  and  route  monitoring.  This  system  will  significantly 
enhance  safety  through  automatic  grounding  avoidance  and  audible  alarms  should  the 
ship  approach  danger  areas.  In  a  brief  dated  6  October  1997,  RADM  Tobin  (N096, 
Oceanographer  of  the  Navy)  addressed  these  issues  in  an  attempt  to  develop  a  cohesive 
transition  plan  and  develop  official  Navy  policy.  Full  fleet  implementation  would  not  be 
completed  until  fiscal  year  2005  [Ref.  28]. 

The  route  planning  available  in  this  system  would  be  enroute  planning  and  assist 
in  course,  speed  and  time  calculations.  It  is  not  the  restricted  water  planning  that  has 
been  the  major  thrust  behind  the  GatorNet  prototype.  Commercial-off-the-shelf  programs 
are  available  that  assist  in  both  types  of  planning.  For  example,  the  Cap’n  is  widely  used 
by  the  fleet  (Chapter  II)  and  is  ideal  for  enroute  planning  where  Fairplay’s  CD-ROM 
contains  a  database  of  port  information  oriented  toward  commercial  shipping  information 
for  the  world’s  ports.  Although  ships  can  use  these  packages,  they  are  not  officially 
sanctioned  for  safety  and  liability  reasons,  and  can  place  Commanding  Officers  in 
difficult  positions  should  they  rely  on  them  to  the  neglect  of  other  official  sources. 

By  the  year  2005,  processor  performance  will  have  doubled  fully  five  times  if 
Moore’s  law  holds  constant.  Optical  devices  will  likely  make  data  storage  a  non-issue. 
Low  orbit  satellite  constellations  will  provide  worldwide  high  bandwidth  connectivity. 
What  type  of  navigation  systems  could  be  built  with  these  capabilities?  The  prospect  of 
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being  stationed  on  the  last  ship  to  receive  yesterday’s  technology  in  the  year  2005  is  not 
very  enticing. 

A.  NAVIGATION  PLANNING  2001— AN  INFOTECH  ODYSSEY 

10  October  2001.  USS  Carl  Vinson  (CVN-70)  has  just  been  upgraded  with  the 
Navy’s  latest  C^ISR  systems  as  it  conducts  work-ups  in  preparation  for  extended 
deployment  to  the  Mediterranean.  The  crew  is  excited  about  it ’s  upcoming  port  call  in 
the  newly  opened  port  of  Havana,  Cuba.  A  search  of  the  Navigation- Archives  CD-ROM 
has  provided  a  good  overview  of  port  services,  and  photographs  of  the  piers  and  tugs 
collected  from  overhead  imagery  and  commercial  ships.  The  tide/current  module 
produces  chartlets  with  graphs  showing  predicted  tides  and  currents  for  the  date  of  the 
planned  transit.  Unfortunately,  the  ship’s  navigator,  LT  Tobin  Jr.,  knows  the 
Commanding  Officer  will  have  many  questions  at  the  Navigation  brief.  He  anxiously  sits 
down  at  his  Pentium  II  300  and  connects  to  the  SIPRNET  to  query  the  “Ports 
Application’’  on  GCCS.  Because  this  is  the  first  US  ship  to  visit  the  port  in  over  40 
years,  he  expects  to  find  very  little  within  the  extensive  lessons  learned  database.  To  his 
surprise,  a  Canadian  combatant  recently  visited  the  port  and  has  included  a  QuickTime 
video  taken  from  their  mast-mounted  camera  during  the  transit.  He  requests  the  video 
and  places  a  priority  level  of  two  on  the  video  information  packet.  Priority  two 
corresponds  to  transmission  over  the  Global  Broadcast  Service  within  the  next  six  hours. 
For  the  meantime,  he  downloads  the  compressed  audio  debrief  given  by  the  Canadian 
Navigator  on  difficulties  encountered  during  the  transit  as  well  as  a  description  of  the 
tugs,  pilot,  and  berthing  facilities.  Just  as  scheduled  he  receives  the  video.  The 
videographer  has  done  a  great  job  highlighting  key  navigation  aids  and  features.  The 
combination  of  the  video  and  the  audio  debrief  answer  many  of  LT  Tobin ’s  questions. 
Knowing  the  system  will  have  automatically  queued  and  compressed  pictures  of  the 
primary  navigation  aids,  with  another  press  of  a  button  he  downloads  the  pictures 
directly  into  the  memory  of  the  recently  arrived  electronic  telescopic  alidades.  The  new 
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devices  have  split  viewfinders  (one  side  digital  image,  other  side  zoom-telescope)  and  are 
networked  to  the  digital  chart  table  to  provide  an  electronic  line  of  position  and 
instantaneous  fix  at  the  push  of  a  button.  These  fixes  are  automatically  compared  with 
DGPS  to  provide  input  to  the  ship 's  autopilot  during  restricted  water  transits. 

Unfortunately,  one  of  the  navaid  files  is  corrupt  so  LT  Tobin  seamlessly  accesses 
the  user  database  to  contact  the  officer  that  submitted  the  file.  After  “whiteboard 
discussion  ”  on  a  digital  chart  overlay  of  the  harbor,  the  Canadian  promises  to  resubmit 
the  automatically  archived  file — all  navigation,  exercise,  and  lessons  learned 
submissions  are  archived  onto  a  personal  removable  Jazz  drive  that  is  assigned  to  the 
user  (the  Canadian  in  this  instance).  As  users  transfer  between  commands,  they  bring 
their  drive  with  them  and  leave  a  copy  at  the  command’s  electronic  data  repository. 
When  individuals  leave  the  service,  the  archives  are  maintained  at  the  central  repository 
for  that  particular  service.  Within  a  day  the  original  file  has  been  retransmitted,  the 
previously  requested  burst  download  of  satellite  imagery  for  the  port  has  been  received, 
and  the  navigation  team  and  Commanding  Officer  feel  exceedingly  well  prepared  to  enter 
a  port  they ’ve  only  virtually  seen. 

Everything  described  within  this  fictional  scenario  is  technically  possible  today. 
The  necessity  for  this  capability  might  be  a  bit  far-fetched  to  make  a  port  call,  but  if  the 
scenario  is  applied  to  a  wartime  amphibious  operation  or  navigation  of  a  minefield  the 
argument  against  this  capability  is  without  substance. 

B.  WHAT  IS  NEXT  FOR  GATORNET? 

The  primary  purpose  behind  a  prototype  is  to  ascertain  user  requirements.  It 
should  be  created  rapidly  to  speed  up  the  system  development  life  cycle  (SDLC).  Since 
there  are  no  known  initiatives  currently  in  progress  to  develop  a  planning  system  like 
GatorNet,  the  goal  has  been  to  generate  discussion  and  feedback  for  a  well-defined 
requirements  package.  Additional  goals  of  the  prototype  were  to: 
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•  Demonstrate  new  navigation-planning  functionality  that  can  be  achieved  with 
Information  Technology  and  little  programming  effort  (photographs,  relational 
database,  lessons  learned) 

•  Change  the  way  navigation  planning  is  conducted,  via  active  submission  of 
lessons/pictures  versus  passively  reading  publications. 

•  Combine  the  numerous  navigation  sources  into  a  “one-stop  shop”  of  information. 

•  Introduce  the  concept  of  an  online  navigation  forum. 

The  National  Image  and  Mapping  Agency  is  in  the  process  of  updating  the  9600 
baud  NavInfoNet  to  a  dynamic  web  site.  If  one  designer  of  the  new  system  accesses 
GatorNet  and  is  influenced  by  the  possibilities  or  implements  one  of  the  concepts,  the 
prototype  will  have  served  its  purpose. 

C.  INTEGRATION  ISSUES  FOR  FLEET  IMPLEMENTATION 

Fielding  a  new  system  with  the  capabilities  displayed  in  the  prototype  raises  many 
integration  issues.  These  issues  have  been  organized  into  architectural,  operational, 
personnel,  cultural  and  economic  categories. 

1.  Architecture  Issues 

Chapter  III  discussed  many  of  the  advantages  and  disadvantages  of  methods  to 
distribute  GatorNet  information.  With  much  of  the  information  fairly  static  (port  data), 
historical  (lessons  learned),  or  in  a  self-contained  program  format  (course/speed/distance/ 
tme  planning  or  tide/current  calculations)  the  requirement  for  an  “on-line”  system  is 
mitigated.  Designing  the  system  to  be  internal  (hard  drive  resident  programs  with  CD- 
ROM  repository),  improves  the  speed  of  the  system  and  frees  up  valuable  bandwidth  for 
other  applications.  However,  there  are  several  functions  that  would  benefit  from  a  real 
time  system  including  safety-related  issues,  retrieval  of  up-to-the-minute  changes,  or  the 
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ability  to  contact  a  user  for  immediate  feedback.  Developing  a  hybrid  system  captures 
both  of  these  advantages. 

The  architecture  issues  that  follow  are  at  the  top  of  the  integrated  Fleet 
Commander  in  Chiefs  priority  list  [Ref  24].  By  the  time  a  GatorNet  system  could  be 
developed  and  introduced  to  the  fleet,  most  of  these  issues  will  likely  be  solved. 

a)  Connectivity — Which  pipe? 

There  are  several  initiatives  to  improve  connectivity  throughout  the 
military.  “C‘*I  for  the  Warrior”  is  the  Joint  Staffs  military  information  architecture 
designed  to  provide  a  fused,  real  time,  true  picture  of  the  warrior’s  battlespace  [Ref.  9:pp. 
6-7].  As  more  systems  are  networked  and  increasingly  more  information  becomes 
available,  greater  demand  will  be  created.  Convincing  intelligence  users,  tactical 
watchstanders,  and  system  administrators  that  the  navigation  planning  evolution  merits 
system  time  will  be  a  difficult  hurdle.  If  this  can  be  accomplished,  creating  a  GCCS 
application  for  navigation  may  be  one  alternative  to  meet  this  new  demand. 

Global  Broadcast  Service  will  provide  an  exponential  increase  over 
current  SATCOM  capacity.  Capitalizing  on  commercially  developed  digital  broadcast 
service  (Direct  TV)  technology,  users  will  request  information  (navigation)  via 
conventional  communications  (e-mail)  and  receive  a  broadcast  (port  images/data)  through 
a  low  cost  receiver  and  small  anteima  [Ref.  12].  This  smart  push/warrior  pull  concept 
provides  a  viable  conduit  for  implementing  the  GatorNet  concept. 

b)  Bandwidth 

How  much  bandwidth  would  a  system  with  GatorNet’ s  functionality 
require?  A  28.8  KBPS  modem  that  results  in  3  KBPS  throughput  of  data  (due  to 
communication  overhead)  has  provided  sufficient  capability  for  prototype  access. 
Bandwidth  at  sea  will  continue  to  be  a  resource  highly  sought  after,  as  more  systems  are 
adapted  to  the  information  age.  Compression  techniques  will  aid  in  reducing  the 
requirements.  Initiatives  such  as  Automated  Digital  Network  System  (ADNS)  will  allow 
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better  sharing  of  bandwidth  and  provide  a  four-fold  increase  in  throughput  efficiency 
[Ref  24].  Although  a  significant  issue,  it  is  already  receiving  considerable  attention  for 
much  higher  bandwidth  applications  such  as  video  teleconferencing. 

Server  side  bandwidth  is  critical  to  ensure  proper  expected  response  to  the 
fleet.  Based  on  the  possibility  of  500  users  simultaneously  requiring  3  KBPS  each,  a 
minimum  100  BaseT,  FDDI,  or  OC-3  connection  should  be  supplied  to  the  network 
access  point  (NAP).  This  currently  is  in  conformance  with  lT-21  standards. 

c)  Storage  Requirements 

By  analyzing  the  rapid  prototype,  a  projection  can  be  made  for  the  data 
storage  size  requirements  of  a  full-scale  implementation.  The  entire  prototype  site  was 
just  over  3  Mb,  but  contained  additional  information  such  as  survey  results,  the  thesis,  as 
well  as  scanned  images  of  charts.  A  fleet  implementation  could  incorporate  portions  of 
vector  format  charts  like  those  used  within  GCCS  applications.  The  San  Diego  harbor  is 
rich  in  navigation  aids  and  contains  more  than  would  normally  be  available  in  the 
“average”  port.  Estimating  that  the  average  port  requires  25  pictures  of  navigation  aids, 
pier  facilities,  and  port  views  and  that  each  picture  is  20  Kb  results  in  500Kb.  Adding 
two  chart  segments  at  50  Kb  each  and  ten  text-based  web  pages  of  information  at  4  Kb 
brings  the  total  port  requirement  to  640  Kb.  An  extremely  robust  set  of  extensive  lessons 
learned  could  bring  the  total  port  size  to  700  Kb.  Using  compression  techniques  well 
over  100  ports  could  be  contained  on  a  single  CD-ROM.  This  approximates  the  number 
of  ports  the  Navy  regularly  visits. 

Theatres  of  operation  could  be  created  such  that  ships  could  download 
information  prior  to  arrival.  By  packaging  the  data  in  compressed  files,  users  could 
retrieve  the  information  while  pierside,  or  during  “off-peak”  times  so  as  not  to  compete 
for  limited  assets.  Flagships  that  have  more  bandwidth  capability  could  download  the 
files  and  distribute  them  to  the  remaining  ships  within  the  task  group  using  Iomega  ZIP 
or  JAZZ  disks.  There  are  many  alternatives  to  distributing  and  disseminating  the 
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information.  The  important  point  to  be  gained  from  the  prototype  is  that  the  file  sizes  can 
be  minimized  and  standard  28.8  KBPS  modems  provide  quick  site  interaction  with 
minimal  delays. 

d)  Standardization 

The  information  required  to  provide  a  comprehensive  navigation  planning 
tool  already  exists.  Digital  Nautical  Charts,  navigation  aid  descriptions,  lessons  learned, 
and  navigation  publications  reside  in  several  independent  repositories.  The  advantage  of 
connecting  these  sources  together  into  a  coherent  system  (band-aid  approach)  would  need 
to  be  weighed  against  creating  a  new  relational  or  object  oriented  database  that  provides 
seamless  integration  of  data.  Whichever  approach  is  taken,  the  system  must  be  Defense 
Information  Infrastructure  Common  Operating  Environment  (DII  COE)  compliant  to 
allow  vvdder  dissemination  [Ref  13].  Using  TCP/IP  and  the  SIPRNET  for  the  online 
portion  of  the  system  is  one  easy  alternative.  Considerable  work  addressing 
standardization  has  been  accomplished  with  the  Common  Operational  Modeling, 
Planning  and  Simulation  Strategy  (COMPASS)  that  establishes  a  set  of  standards  for  Cl 
system  and  modeling  and  simulation  system  interaction.  [Ref.  8]. 

Developers  of  a  follow  on  application  to  GatorNet  must  balance  the  need 
for  adequate  detail  within  graphics  while  minimizing  file  size  to  reduce  transfer  times.  A 
standard  would  need  to  be  set  for  compression  factors  to  ensure  a  minimum  resolution 
was  maintained.  To  ensure  users  understand  the  compression  factors  and  to  prevent 
misinterpretation  of  photographs,  each  image  could  either  be  annotated  or  have  a 
corresponding  database  field  to  display  the  compression  value  when  the  picture  is 
displayed.  Defining  these  and  other  data  standards  and  functionality  is  the  first  step  in  any 
system  development. 

e)  Reliability  and  Accountability 

Any  system  that  will  provide  navigation  planning  information  must  have 
complete  reliability.  This  explains  the  prolonged  use  of  hardcopy  chart  and  publications 
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within  the  Navy,  If  a  ship  must  go  into  harms  way,  not  having  access  to  the  necessary 
tools  or  information  is  unacceptable.  This  requirement  calls  for  the  minimum  planning 
tools  to  be  incorporated  in  a  self-contained  system — one  that  is  not  reliant  on  external 
communication  sources  beyond  the  navigator’s  control.  Navigation  information  is 
currently  updated  through  the  mail  on  a  weekly  basis.  If  a  ship  is  transiting  OP  AREAS  in 
the  Indian  Ocean,  quite  often  conventional  mail  can  be  delayed  up  to  a  month.  Although 
a  self-contained  vessel,  a  naval  ship  cannot  conduct  its  mission  today  in  politically 
sensitive  climates  without  access  to  Command  and  Control  conduits.  The  line  must  be 
drawn  somewhere  between  online  reliability  and  internal  systems.  Designing  a  system 
to  run  on  an  IT-21  compliant  personal  computer  that  can  quickly  access  a  network  for 
compressed  program/safety  updates  should  be  the  minimum  approach.  As  a  backup,  the 
defense  message  system  could  always  be  used  to  send  safety  related  information  should 
the  primary  network  be  unavailable. 

f)  Security 

The  vast  majority  of  navigation  information  is  unclassified  and  widely 
available  in  open  sources.  Should  the  system  be  expanded  to  include  exercise  data  or 
navigation  contingency  plans,  greater  security  would  be  required.  Coimnercial  mariners 
could  provide  significant  feedback  to  a  navigation  repository,  but  this  adds  the 
requirement  of  protecting  the  data  from  deliberate  manipulation  or  denial  of  service 
attacks.  Since  the  system  has  national  security  implicatioiis,  keeping  it  within  DoD  is  the 
best  way  of  providing  security.  Using  a  protocol  that  supports  encryption  and  a  conduit 
that  protects  the  information  (SIPRNET)  is  the  most  feasible  answer. 

2.  Operational  Issues 

Assuming  a  planning  system  is  developed,  how  would  information  be  gathered  to 
increase  the  system’s  utility?  Many  of  the  mechanisms  are  currently  in  place.  NIMA  and 
the  US  Coast  Guard  already  gather  and  update  the  primary  navigation  planning 
publications.  Ships  are  tasked  to  submit  port  visit  reports  to  update  the  Port  Directory. 
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Many  fleet  commanders  require  lessons  learned  messages  to  be  included  in  passdown 
folders.  Collecting  all  this  information  into  one  location  requires  a  centralized  point  of 
contact. 

Adding  shipboard  procedures  to  collect  meaningful  photographs  would  only 
require  prior  planning.  The  manning  is  in  place  (Photographer’s  mates  could  be  tasked  or 
any  individual  not  involved  in  the  sea  detail)  and  the  equipment  is  available.  With  the 
improvement  in  digital  cameras,  uploading  photographs  would  be  straightforward.  If 
pictures  can’t  be  taken  during  the  transit,  quartermasters  could  use  the  Captain’s  gig  or 
motor  whaleboat  to  document  the  harbor  once  in  port. 

Gathering  data  would  also  be  simple  if  electronic  debrief  forms  are  available  to 
capture  information  following  each  and  every  navigation  evolution.  These  forms  could 
be  transmitted  immediately  if  cormectivity  is  available,  or  stored  for  later  transmission  or 
submission  via  postal  service  on  disk.  The  biggest  hurdle  would  be  changing  the  mindset 
of  the  users.  Once  the  advantages  that  can  be  gained  are  apparent,  user  support  should 
follow.  Training  can  be  conducted  within  the  fleet  navigation  schoolhouses.  Or  could  be 
accomplished  through  distance  learning  programs. 

3.  Personnel  Issues 

Maintaining  an  online  site  with  vast  quantities  of  data  would  require  considerable 
support  during  the  “build-up”  phase.  Once  the  majority  of  frequently  visited  port 
information  was  converted  or  documented,  manning  could  be  reduced  to  support 
incremental  updates  and  requests.  A  small  staff  savvy  in  the  selected  system  architecture 
and  navigation  issues  should  be  able  to  manage  the  project  at  that  point.  A  staff  could  be 
comprised  of  two  senior  quartermasters,  a  junior  enlisted  individual  for  graphics  support, 
a  system  administrator  and  an  arrangement  for  part-time  maintenance.  Owning  a  large 
portion  of  the  data  and  having  direct  access  to  the  infrastructure,  NIMA  seems  the  logical 
choice  to  manage  such  a  system. 
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Naval  decision-makers  are  fully  onboard  with  Information  Technology  being  used 
as  a  way  to  leverage  our  shrinking  fighting  forces.  As  world  commitments  persist  and 
deployment  turnaround  schedules  shrink,  manning  issues  will  surely  plague  the  Navy. 
Much  of  the  quartermaster’s  time  is  spent  maintaining  charts  and  publications,  or  laying 
tracks  and  calculating/graphing  tides  and  currents.  Adopting  a  navigation  planning 
system  that  can  reduce  the  manning  requirements  is  certainly  advantageous. 

4.  Cultural  Issues 

One  of  the  most  difficult  issues  surrounding  this  concept  is  that  of  culture.  The 
Navy  is  steeped  in  traditions  and  one  of  the  earliest  is  precise  navigation  on  the  high  seas. 
The  adversity  to  changing  procedures  and  accepting  Information  Technology  has 
diminished  as  captured  by  the  fleet  survey  results.  Many  of  the  sailors  and  officers  utilize 
computers  and  are  familiar  with  their  potential  capability  if  applied  to  the  navigation 
planning  process.  By  the  time  a  new  planning  system  could  be  implemented,  many 
remaining  “resistors”  will  have  retired 

5.  Economic  Issues 

In  this  day  of  declining  budgets,  hard  decisions  are  being  made  over  which 
systems  will  be  funded,  which  ones  will  receive  upgrades,  and  those  that  will  be  cut. 
Although  a  considerable  up-front  investment  would  be  needed  to  design  a  new  planning 
system,  the  savings  that  can  be  generated  through  reduced  paper  products,  distribution 
costs,  mainteneince  costs,  and  personnel  should  justify  the  expenditure  over  the  years.  The 
intangible  cost  associated  with  the  negative  publicity  surrounding  a  ship’s  grounding  or 
collision  is  hard  to  quantify.  If  a  more  comprehensive  and  current  planning  system 
prevents  a  single  ship  from  running  aground  the  system  will  have  paid  for  itself. 

Combining  development  efforts  between  the  Coast  Guard,  National  Ocean 
Service,  and  NIMA  could  reduce  costs.  Both  will  have  an  online  presence  through 
NAVCEN  and  NAVINFONET.  Both  the  Coast  Guard  and  NIMA  have  similar  concerns 
over  navigation  safety.  The  key  to  keeping  costs  at  a  minimum  is  to  take  advantage  of  the 
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research  and  development  for  related  systems  building.  As  mentioned  earlier,  NIMA  is 
in  the  process  of  revamping  the  NAVINFONET.  GCCS  has  well  defined  standards  for 
data  format  and  transmission,  and  many  applications  are  being  added  to  the  system. 

D.  FRAMEWORK  FOR  MANAGING  PLANNED  CHANGE 

The  primary  deterrent  against  implementing  planning  concepts  from  GatorNet 
will  likely  come  down  to  a  choice  in  priorities.  Ships  have  been  navigating  in  and  out  of 
world  ports,  through  narrow  straits,  and  within  swept  channels  of  mine  fields  without 
having  the  coordinated  suite  of  planning  tools  discussed  in  GatorNet  for  many  years. 
GPS  has  significantly  improved  ship  safety  near  shore,  and  DGPS  is  improving  the 
accuracy  to  within  meters.  The  systems  can  already  be  used  as  a  viable  backup  to  visual 
and  radar  procedures  within  restricted  waters.  With  other  navigation  initiatives  like  DNC 
and  ECDIS  in  the  limelight,  GatorNet  could  easily  be  deemed  a  low  priority  as  programs 
compete  for  limited  funds.  Unfortunately,  these  arguments  could  be  made  for  many  years 
to  come  as  new  programs  emerge.  So  how  should  the  fleet  users  who  are  obviously  ready 
and  willing  to  change  (Chapter  II)  influence  navigation  plaimers? 

1.  Is  the  Navy  Ready  to  Change? 

Until  recently,  an  argument  for  changing  navigation  planning  methods  would 
have  been  difficult  to  support.  The  infrastructure  for  any  sort  of  online  system  was  not  in 
place.  Computers  with  CD-ROMS  and  certainly  networks  onboard  ships  were  limited. 
But  now  that  these  issues  are  being  resolved,  the  remaining  obstacle  is  changing  the  way 
we  present  and  distribute  information  that  (for  the  most  part)  is  already  being  collected. 

Fleet  users  are  increasingly  computer  savvy.  They  are  aware  of  the  leverage  that 
can  be  gained  through  Information  Technology.  They  thrive  on  technology  and  do  not 
fear  it  like  many  previous  decision-makers.  The  culture  is  ripe  for  change,  but  is  the 
Naval  Organization  ready  for  change? 
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The  Harvard  Business  School  article  Leading  Change  presents  a  conceptual 
formula  that  incorporates  the  critical  dimensions  of  change  that  must  be  taken  into 
consideration: 

Amount  of  Change  =  (Dissatisfaction  *  Model  *  Process)  >  Cost  of  Change 
Dissatisfaction  is  the  source  of  energy  that  motivates  change  within  the  organization  [Ref. 
29].  Although  many  navigators  may  see  the  benefits  of  or  prefer  a  new  planning  system, 
how  many  are  actually  dissatisfied  with  the  current  system?  The  fleet  survey  identified 
quartermasters  that  are  frustrated  with  the  need  to  correct  publications  and  charts  instead 
of  having  digital  charts  with  computer  updates.  There  are  navigators  that  haven’t  used 
the  current  lessons  learned  system  or  find  it  difficult  to  access.  But  these  issues  miss  the 
central  themes  behind  GatorNet.  To  raise  dissatisfaction,  users  must  first  see  what  they 
are  missing.  The  GatorNet  prototype  should  raise  awareness  and  hopefully  increase 
dissatisfaction. 

There  are  many  models  used  to  evaluate  an  organization’s  fundamental  aspects — 
structure,  processes,  environment,  people,  strategies,  tasks,  and  culture  to  name  a  few 
aspects.  Once  the  relationships  between  these  aspects  are  understood,  it  is  easier  to 
determine  which  lever  should  be  pulled  to  initiate  change.  A  future  model  of  navigation 
planning  is  needed  as  a  vision  that  would  help  galvanize  the  change  effort.  DoD  is  adept 
at  creating  visionary  documents  and  programs  for  overarching  efforts  (such  as  JV2010, 
Copernicus,  and  C4I  for  the  Warrior).  The  program  managers  in  charge  of  navigation 
planning  need  to  create  a  realistic  visionary  model  that  the  organization  can  strive  toward. 

A  roadmap  must  be  defined  to  aid  in  the  change  process.  Users  need  to  be 
brought  into  this  process  not  only  to  obtain  accurate  requirements  (fleet  survey/evaluation 
of  GatorNet),  but  also  to  buy  into  the  change  process.  From  the  survey  results,  the 
majority  of  users  appear  to  have  “bought  in”;  now  a  change  process  needs  to  be  defined. 

The  equation  states  the  product  of  dissatisfaction,  model  and  process  must  be 
greater  than  the  cost  of  change  to  achieve  success.  The  costs  associated  with  changing 
navigation  planning  are  more  than  monetary.  There  is  still  a  small  cadre  of  “old-timers” 
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that  believe  in  traditional  navigation.  NTIC  lessons  learned  stakeholders  may  be 
threatened  by  a  new  system— the  survey  suggests  the  system  has  failed  regarding 
navigation.  Users  of  limited  bandwidth  would  see  another  system  competing  for  limited 
resources.  The  time  required  to  develop  and  maintain  this  system  would  detract  from 
others.  The  additional  time  required  for  users  to  assist  in  populating  databases  with 
quality  lessons  learned,  photographs  and  voyage  feedback  would  add  to  an  existing 
workload. 

The  amoxuit  of  change  likely  to  take  place  given  this  equation  does  not  seem 
promising.  However,,  one  advantage  of  military  decision-makers  is  the  ability  to  order 
change  and  know  it  will  be  accepted.  Given  a  properly  designed  system,  once  users 
experience  the  vast  information  stores  that  can  easily  be  placed  at  their  fingertips  they 
will  wish  they  had  initiated  change  ten  years  earlier. 

2.  When  to  Implement  Change? 

The  Harvard  Business  School  Note:  “The  Challenge  of  Change”  [Ref.  30] 
indicates  the  process  of  change  “may  be  easier  when  the  organization  is  in  crisis:  the 
situation  is  clear  to  all,  survival  is  on  the  line;  everyone  recognizes  that  the  way  things 
have  been  done  won’t  work  anymore.”  There  is  no  navigation-planning  crisis  present  that 
will  force  the  Navy  to  change.  No  crisis  was  needed  to  initiate  the  transitional  change 
that  has  already  begun.  Navigation  publications  are  now  being  distributed  on  CD- 
ROMS.  A  formalized  lessons  learned  system  now  exists  where  one  did  not  in  1991.  All 
admirals  and  most  commeinds  now  have  e-mail  addresses.  Ships  are  being  networked. 
IT-21  is  providing  the  equipment  necessary  to  implement  a  hard-drive  resident  database 
program,  CD-ROM  archive,  or  Windows  NT  client-server  planning  tool.  Many 
initiatives  are  in  place  to  increase  connectivity  at  sea.  With  all  these  changes  already 
taking  place,  it  is  time  to  redefine  how  we  conduct  navigation  planning  and  harness  these 
advances  toward  a  coordinated  navigation  planning  system. 
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VI.  CONCLUSIONS 


A.  SUMMARY  OF  FINDINGS 


1.  Project  Accomplishments 

Accomplishments  of  the  thesis  project  are  summarized  as  follows: 
a)  Research  Achievements 

•  A  review  of  existing  navigation  planning  procedures  was  conducted  and 
documented  in  Chapter  I. 

•  A  study  of  existing  fleet  navigation  information  sources  and  initiatives  was 
conducted  and  results  were  documented  in  Chapter  I. 

•  An  analysis  of  how  to  improve  the  existing  navigation  planning  process  was 
conducted  and  results  were  documented  in  Chapters  II  and  V. 

•  A  study  of  migration  alternatives  was  conducted  and  documented  in  Chapter 
III. 


h)  Rapid  Prototype 

A  conceptual  Navigation  Planning  Information  Architecture  was  proven  via 
the  GatorNet  rapid  prototype  navigation-planning  tool  described  in  Chapter  IV.  The 
benefits  of  client-server  information  technology  and  potential  benefits  for  the  fleet  have 
been  shown.  A  relational  database  of  navigation  lessons  learned  and  a  graphical  Web- 
based  user  interface  were  developed  in  the  prototype  to  permit  interaction  with  the 
database.  The  prototype  “GatorNet”  is  on-line  and  is  available  for  viewing  (as  of  the 
publishing  of  this  thesis)  at:  http://pcicml.ece.nps  navv.mil/Gatorhome.htm. 

c)  User  Requirements  Document 

A  fleet  survey  was  developed  and  distributed  to  generate  feedback,  which 
has  been  consolidated  into  a  requirements  document.  These  requirements  were 
documented  in  Chapter  II  and  Appendix  E. 
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2. 


Lessons  Learned 


a)  Positive  Lesson  Learned 

A  positive  lesson  from  the  project  was  that  a  full  year  was  allowed  to 
conduct  the  research  necessary  to  develop  the  prototype.  This  year  was  actually  needed  in 
order  to  involve  the  navigation  “users”  in  the  process  as  mentioned  in  Chapter  V  (section 
D.l).  This  capture  of  positive  lessons  is  in  keeping  with  the  Chapter  IV  (section  A.2) 
recommendation  to  capture  positive  lessons  along  with  negative  lessons  from  the  fleet. 

b)  Netscape  Enterprise  Server  Installation 

An  unsuccessful  attempt  was  made  to  use  non-Microsoft  server  software: 
Netscape  Enterprise  Server.  This  may  have  been  due  to  the  proprietary  nature  of 
commercial  software  design  and  the  fact  that  all  other  software  in  the  prototype  suite  was 
either  a  Microsoft  product  or  a  Microsoft  compatible  product.  Once  a  Microsoft  server 
product  was  used  (Internet  Information  Server)  there  were  no  more  compatibility 
problems  encountered. 

c)  Prototype  Development  Timeline 

The  original  project  milestone  date  to  complete  prototype  development 
was  not  met.  Three  more  months  were  needed  to  complete  and  publish  the  prototype, 
because  ample  time  was  not  allowed  to  learn  the  new  software.  If  the  original  date  had 
been  achieved,  more  effort  could  have  been  expended  to  continue  to  keep  the  users 
involved,  so  that  additional  feedback  could  be  incorporated  into  future  prototype 
revisions. 
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B.  PROJECT  CONCLUSIONS 


1.  Smart  Ship  Navigation  Initiatives:  A  Good  First  Step 

The  SMART  SHIP  project  described  in  Chapter  I  was  initiated  by  the  Naval 
Research  Advisory  Committee  and  the  Chief  of  Naval  Operations,  and  the  operational 
platform  chosen  was  the  USS  YORKTOWN  (CG-48).  The  project  has  been  considered 
by  many  to  be  a  major  success,  mainly  because  commercial-oflf-the-shelf  (COTS) 
technology  was  added  to  the  existing  ship’s  systems  to  achieve  new  efficiencies  and  help 
to  reduce  manning  by  17%  [Ref  31],  According  to  a  senior  Navy  official,  “YORKTOWN 
was  able  to  cut  billets  off  the  ship  by  introducing  technology  and  by  letting  the  crew  come 
up  with  better  ways  of  doing  things.”  [Ref  32]  The  same  official  stated  that  the 
efficiencies  developed  in  YORKTOWN  were  gained  by  implementing  “out-of-the-box 
ideas”  generated  on  that  ship.  The  ship  found  its  new  navigation  efficiencies  by  using 
Digital  Nautical  Charting,  the  NAVSSI  system,  Sperry’s  Voyage  Management  System, 
and  by  reducing  their  chart  inventory  of  two  sets  of  up-to-date  paper  charts  to  one  set.  By 
eliminating  their  holdings  of  redundant  copies  of  paper  charts,  they  reduced  the  weekly 
chart  maintenance  hours  by  50%  [Ref  33]. 

2.  Fleet  Navigators  are  Ready  for  Automated  Navigation  Planning 

The  authors  were  extremely  encouraged  to  learn  that  the  U.  S.  Navy  navigation 
“users”  support  for  automating  manual  navigation  planning  tasks  is  nearly  unanimous 
(Appendix  E).  The  findings  from  the  survey  show  that  it  is  widely  recognized  that 
opportunities  exist  to  gain  efficiency  by  automating  manual  navigation  planning  tasks,  such 
as  data  collection  and  processing.  However,  maintaining  one  complete  set  of  paper  charts 
onboard  ship,  as  is  the  practice  aboard  YORKTOWN,  may  be  prudent  for  use  as  a  “Battle 
Backup”  method  of  navigating  without  reliance  on  communication  satellites  or  computers, 
which  may  become  casualties  in  combat. 
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3.  The  Coast  Guard  is  Ahead  of  the  Navy  in  Digitizing  Navigation 

Significant  navigation  advances  have  taken  place  onboard  U.  S.  Coast  Guard 

vessels,  as  evidenced  by  the  USCGC  JUNIPER’S  use  of  new  navigation  technology. 

Having  been  commissioned  in  early  1996,  JUNIPER  was  called  on  to  coordinate  early 

efforts  to  recover  aircraft  wreckage  from  the  TWA  Flight  800  disaster.  JUNIPER’S  early 

ocean  floor  wreckage  survey  was  conducted  using  DGPS  and  new  voyage  management 

software  to  successfully  map  ocean  floor  wreckage  and  to  autopilot  the  ship  to  maintain  a 

continuous  position  on  top  of  wreckage.  To  summarize  this  process: 

The  Juniper  uses  a  GPS  receiver  as  part  of  a  shipboard  fiber-optic  local- 
area  network  (LAN).  The  LAN  runs  two  key  PC-based  software 
packages:  the  Electronic  Charting  System,  a  computerized  nautical  chart 
developed  by  Offshore  Systems  Ltd.;  and  the  Dynamic  Routing  System,  a 
navigation  software  package  created  by  Nautronix.  By  combining  these 
programs  with  the  positioning  information,  the  ship  has  the  capability  to 
drive  itself  The  computer  system  enabled  the  JUIOTER  to  hold  in  place 
automatically  by  monitoring  the  GPS  information  and  engaging  thrusters  or 
propellers... the  crew  could  run  on  autopilot  with  precision  by  laying  out  a 
course  on  the  electronic  chart  and  then  feeding  it  into  the  Dynamic  Routing 
System.  The  JUNIPER  tapped  into  the  Differential  GPS  System  (DGPS) 
which  fine-tuned. .  .the  position  to  an  accuracy  of  two  meters  [Ref  34]. 


This  superior  new  technology  has  not  yet  been  installed  aboard  Navy  ships,  but  the 
new  systems  (NAVSSI  and  VMS)  and  initiatives  proven  in  YORKTOWN  are  a  much- 
needed  step  in  the  right  direction.  JUNIPER’S  technology  demonstrates  the  feasibility  of 
allowing  computer  systems  to  autopilot  ships  into  port.  It  is  conceivable  that  in  the  future, 
ship  visual  navigation  teams  may  serve  only  a  supervisory  role. 

A  primary  mission  of  the  U.  S.  Coast  Guard  is  to  promote  the  safety  of  marine 
navigation.  The  Coast  Guard  does  a  thorough  job  of  centrally  managing  navigation  issues 
such  as  notices  to  mariners  through  the  centrally  managed  NAVCEN  WWW  site. 
NIMA’s  Marine  Navigation  WWW  or  SIPRNET  page  could  be  improved  along  these 
lines,  by  changing  the  current  static  design  to  an  active  one,  which  would  allow 
continuous  updates  to  navigation  data. 
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4.  The  Network  Centric  Warfare  Concept  Should  Include  Navigation 
Planning 

The  United  States  Navy’s  leadership  has  embarked  on  an  ambitious  plan  to 

leverage  computer  network  technology  in  such  a  way  that  all  administrative  and  even 

tactical  functions  are  driven  to  the  desktop  computer;  the  IT-21  vision.  Network  Centric 

Warfare  is  a  related  concept  of  VADM  Cebrowski,  the  Deputy  Chief  of  Naval  Operations 

for  communications  and  computer  matters.  VADM  Cebrowski’ s  concept. 

Holds  enormous  potential  for  the  surface  navy.  If  you  consider  an  Internet 
web  page  analogy.  Network  Centric  Warfare  will  establish  a  wide  area 
network  of  reliable  satellite  connectivity.  In  the  past... it  was  only  within 
the  (ship’s)  hfelines  that  you  were  able  to  pull  together  disparate  data  and 
make  sense  out  of  it  in  a  given  situation.  Now  the  data  for  a  particular 
mission  is  available  to  be  pulled  down. .  .from  the  Internet.  This  will  allow 
us  to... maximize  the  combat  capabilities  of  all  our  surface  platforms. 
Network  Centric  Warfare  will  accelerate  the  information  processing 
function  and  then  distribute  it  to  the  total  force.  Ships  in  large  numbers 
will  then  have  the  connectivity  and  tools  available  to... conduct  mission 
planning,  without  having  to  rely  on  the  large  decks  (such  as  aircraft 
carriers)  [Ref  35]. 


In  addition  to  the  Network  Centric  Warfare  concept,  a  “System  of  Systems” 
approach  to  manage  heterogeneous  navigation  data  and  applications  is  also  needed  [Ref 
36].  The  GrCCS  system  is  a  perfect  example  of  such  a  combination  of  systems.  Numerous 
joint  navigation  applications  and  data  sources  could  therefore  be  combined  into  a  single 
powerful  tool,  thereby  allowing  true  “one  stop  shopping”  when  it  is  time  to  plan  a 
navigation  evolution. 

5.  There  is  a  Definite  Trend  Within  the  Navy  to  Move  Toward  Digital 
Navigation 

The  new  attack  submarine  (NSSN)  is  being  built  with  no  chart  stowage  onboard. 
[Ref.  28]  This  is  a  significant  indication  that  the  U.  S.  Navy  is  committed  to  doing  away 
with  paper  charts  and  eventually  migrating  to  a  fully  digital  method  of  navigation: 

The  technological  revolution  has  additionally  impacted  naval  operations 

with  respect  to  GGI&S  (Global  Geospatial  Information  and  Services).  The 
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Navy,  in  concert  with  NIMA  (National  Imagery  and  Mapping  Agency), 
and  national  and  international  organizations,  is  moving  to  utilize  a  vector 
database  keyed  to  positional  information  from  GPS,  to  provide  electronic 
navigational  charting.  The  present  goal  is  to  utilize  the  Digital  Nautical 
Chart  (DNC)  (TM)  with  worldwide  production  by  1999.  ...In  a  parallel 
development,  the  New  Attack  Submarine  (NSSN)  is  being  designed 
without  chart  lockers  and  will  folly  employ  digital  charts  and  electronic 
navigation.  Fully  integrated  navigation  systems  are  clearly  a  long-term 
goal,  but  in  the  short  term,  we  are  encouraging  the  use  of  stand-alone 
electronic  charting  systems  that  are  ready  now  to  dramatically  improve 
situational  awareness  for  our  bridge  watch  teams  [Ref  37]. 

In  addition  to  the  significance  of  a  new  vessel  without  paper  charts,  there  is  another 
important  acknowledgement  in  the  previous  quote:  that  a  folly  integrated  navigation 
system  is  needed.  Navigation  planning  functions  must  be  included  in  any  new  integrated 
system. 


6.  Navigation  Tradition  and  Culture  Paradigms  Need  to  Shift 

An  uncomfortable  tradition  exists  in  the  Navy  regarding  a  ship  grounding:  A 

ship’s  Captain  and  Navigator  are  guilty  until  proven  innocent.  Any  such  incident  almost 

always  results  in  the  end  of  the  careers  of  any  officers  involved  with  such  a  misfortune. 

This  fearful  tradition  will  make  any  changes  to  the  paper  method  of  navigation  a  tough 

paradigm  to  crack.  Fortunately,  Navy  attitudes  toward  the  culture  of  computer  network 

technology  are  shifting,  thanks  to  initiatives  like  IT-21  and  others: 

As  the  information  age  in  the  Navy  is  poised  to  enter  the  (next)  phase  of 
development,  we  must  go  beyond  simply  improving  our  tools,  and  instead 
leverage  those  tools  to  fundamentally  change  our  processes.  This  is  the 
philosophy  behind  IT-21 .  It  is  a  paradigm  shift  in  how  we  create,  manage, 
and  retrieve  information  [Ref  38]. 

In  1997,  YORKTOWN  navigated  to  a  precision  anchorage  in  the  Chesapeake  Bay 
using  the  autopilot  feature  of  the  Sperry  Marine  Voyage  Management  System.  When 
shifting  to  computer  ship  control,  the  ship’s  officers  give  the  command  to  the  bridge 
console  operator:  “Shift  control  (of  the  ship)  to  the  VMS!”  The  Naval  Research  and 
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Advisory  Committee  (NRAC)  panel  reported  that  the  major  obstacles  to  (SMART  SHIP) 
reduced  manning  and  decreased  life  cycle  costs  aboard  Navy  ships  were  culture  and 
tradition  rather  than  the  lack  of  proven  technology  and  know-how.  Further,  that 
expenditures  on  available  technology  and  implementation  of  policy  and  procedure  changes 
make  manpower  reductions  achievable  [Ref  3 1], 

C.  RECOMMENDATIONS 

1.  Continue  Reflnement  of  GatorNet  Prototype 

The  GatorNet  prototype  does  not  yet  contain  enough  hard  data  for  fleet 
implementation.  Continued  refinement  of  the  system  and  widespread  exposure  to  the  fleet 
will  help  to  further  refine  user  requirements.  With  a  larger  database  repository  (e.g.  all 
West  coast  ports  photographed  and  substantially  more  lessons  learned),  GatorNet  may 
eventually  be  added  to  a  SMART  SHIP  or  SMART  GATOR  platform  as  an  experimental 
system  in  the  very  near  future. 

2.  Migrate  GatorNet  to  the  SIPRNET 

Use  the  SIPRNET  as  the  C4ISR  conduit  and  complete  development  of  the 
GatorNet  prototype  into  a  beefed-up  GCCS  “Ports”  application.  Although  the  majority  of 
navigation  information  is  unclassified,  any  data  or  planning  system  is  extremely  vulnerable 
to  Information  Warfare.  Because  the  security  of  this  information  is  of  vital  importance  to 
ship  safety,  it  should  be  afforded  a  high  level  of  protection  such  as  that  provided  by  the 
SIPRNET  and  GCCS. 

This  migration  should  be  managed  to  coincide  with  the  NIMA  initiative  to  digitize 
all  navigation  products  for  placement  on  the  SIPRNET  by  the  end  of  1998. 

3.  Transition  the  NTIC  NLLS  to  the  SIPRNET  Through  an  On-Line, 
Interactive  Client-Server  Database  Back-end 

As  shown  in  Chapter  II  (Table  2-8),  very  few  fleet  users  are  using  the  current 
lessons  learned  system.  An  on-line  system  would  save  the  considerable  distribution  costs 
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associated  with  the  current  method  of  quarterly  CD  ROM  updates.  Transitioning  the 
NTIC  NLLS  to  a  secure  system  such  as  the  SIPRNET  would  avail  fleet  users  and  other 
interested  joint  military  planners  of  the  latest  lessons  learned.  Due  to  the  ease  of  access  of 
an  on-line  system,  more  lessons  can  be  captured,  including  positive  lessons  along  with  the 
negative  ones.  In  addition,  capturing  quantitative  lesson  data  (along  with  qualitative 
information)  would  allow  statistical  analysis  (e.g.  rating  averages)  and  a  revised  lesson 
questionnaire  format  could  help  to  facilitate  this. 

4.  Designate  a  Single  Agency  to  Manage  all  Migration  Issues  Associated 
with  Automating  Navigation 

During  research  for  the  thesis,  it  became  obvious  to  the  authors  that  there  are 
several  U.  S.  Government  initiatives  underway  to  improve  maritime  navigation.  Some  of 
these  initiatives  were  described  in  Chapter  I.  This  thesis  has  addressed  an  area  believed  to 
be  wholly  overlooked,  which  is  the  issue  of  migrating  manual  navigation  planning  tasks  to 
automated  methods.  There  exists  a  glaring  need  for  our  government  and  military  to 
designate  a  single  responsible  office  to  coordinate  and  harmonize  the  numerous 
fragmented  efforts  currently  underway.  An  annual  national  professional  navigation 
conference  or  symposium  would  also  greatly  benefit  all  interested  parties,  such  as  the 
United  States  Navy,  the  United  States  Coast  Guard,  the  National  Imagery  and  Mapping 
Agency,  the  National  Ocean  Service,  and  the  Maritime  Administration. 

D.  SUGGESTED  AREAS  FOR  FURTHER  STUDY 

1.  Conduct  a  Study  of  All  of  the  Latest  Navigation  Voyage  Management 
Software 

The  Full  Utility  Navigation  Demonstration  (FUND)  software  initial  version  was 
just  released  in  December,  1997  [Ref  20].  The  Defense  Mapping  Agency  Mapping, 
Charting,  and  Geodesy  Utility  Software  Environment  (DMAMUSE)  program  is  another 
ECDIS  software  title  which  should  be  reviewed  in  order  to  explore  the  feasibility  of 
navigation  planning  product  compatibility.  Can  these  software  packages,  which  were 
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primarily  designed  to  manage  electronic  charts,  also  be  leveraged  to  accept  the  full  range 
of  heterogeneous  digital  navigation  planning  products? 

2.  Conduct  a  Review  of  all  Relevant  Databases  that  Contain  Navigation 
Information 

A  review  of  navigation  data  sources  should  be  conducted.  This  will  most  likely 
require  extensive  travel  and  an  appropriate  security  clearance,  as  some  data  is  resident  in 
classified  databases.  The  National  Imagery  and  Mapping  Agency  headquarters  in 
Northern  Virginia  is  a  good  place  to  start  this  study.  In  addition  to  surveying  what 
databases  (both  commercial  and  military)  are  relevant  to  navigation  planning,  methods  of 
integrating  and  consolidating  the  disparate  data  should  be  explored. 

3.  Investigate  the  Feasibility  of  Marrying  Littoral  Digital  Overhead 
Imagery  with  Navigation-Planning 

There  exists  in  the  fleet  a  tremendous  need  for  easy  access  to  near-shore  and  beach 
overhead  imagery  to  help  support  key  decision-makers  in  the  planning  for  amphibious  and 
special  operations.  An  appropriate  tool  needs  to  be  developed  to  properly  identify  and 
label  such  imagery,  which  has  navigational  value.  For  example,  littoral  imagery  might 
show  the  presence  of  heavy  offshore  kelp,  which  could  foul  the  screws  (propellers)  of 
certain  displacement  landing  craft  and  cause  decision-makers  to  opt  to  use  air  cushion 
landing  craft.  Similarly,  littoral  imagery  might  also  show  the  presence  of  beach  obstacles 
(either  natural  or  man-made)  or  an  unknown  offshore  sandbar  that  might  make  a  particular 
amphibious  or  expeditionary  operation  infeasible  or  unacceptably  risky.  In  many  cases, 
existing  imagery  could  be  used  rather  than  brand-new  products.  If  necessary,  national 
assets  could  be  tasked  in  a  crisis  to  develop  this  navigation-specific  imagery,  which  could 
be  pushed  to  plaimers  through  robust  intelligence  networks  already  in  place  in  the  fleet.  A 
method  needs  to  be  developed  to  screen  all  near-shore  imagery  and  label  or  tag  those 
images  which  have  navigational  value,  so  that  they  can  be  “pulled”  by  warfighters  to  aid  in 
time-sensitive  operational  decisions. 
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APPENDIX  A.  LIST  OF  NAVIGATION  PLANNING  PUBLICATIONS  AND 

PRODUCTS 

This  listing  shows  the  majority  of  the  hard-copy  publications,  charts,  messages, 
and  other  products  which  are  used  in  the  manual  navigation  planning  process. 

•  COMNAVSURFLANT/COMNAVSURFPAC/AIRPAC/AIRLANTINST 
3530.4:  Surface  Ship  Navigation  Department  Organization  and  Regulations 
Manual 

•  Pub.  9,  American  Practical  Navigator 

•  Nautical  Charts 

•  NIMA  Fleet  Guides 

•  Port  Directory 

•  Pub.  150,  World  Port  Index 

•  Pub  .151,  Distance  Between  Ports 

•  Pub.  152,  Sailing  Directions  (Planning  Guides) 

•  Pub.  153,  Sailing  Directions  (Enroute) 

•  Notice  to  Mariners  (NIMA/NOSAJ.S.  Coast  Guard) 

•  Local  Notice  to  Mariners  (U.S.  Coast  Guard) 

•  Light  List  (U.S.  Coast  Guard) 

•  List  of  Lights  (NIMA) 

•  Navigation  Rules  (COMDTINST  Ml 6672.2C) 

•  U.S.  Coast  Pilots 

•  Tide  and  Current  Tables 

•  Pub.  606,  Guide  to  Marine  Observation  and  Reporting 

•  Summary  of  Chart  and  Publication  Corrections 

•  HYDROPAC/LANT  Safety  Messages 

•  Nautical  Almanac 

•  Typhoon/Hurricane  Havens  Handbook 
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APPENDIX  B.  FLEET  NAVIGATION  SURVEY 


Note:  Although  you  may  not  currently  have  access  to  the  World  Wide  Web,  please  assume  you  have  it  or  will  have  it 
in  the  near  future  when  responding  to  these  questions.  Please  feel  free  to  use  additional  sheets  for  your  responses,  if 
necessary.  Also,  please  indicate  ‘‘N/A’’  for  questions  which  do  not  apply  to  your  situation. 

1 .  Please  provide  the  following  information: 

Rank  Title _  Time  in  billet  (mos) _  #  QMs  on  board 

Command  (Staff  or  ship  platform  (i.e.  DESRON,  CV,  etc.) _ 

Current  command  status  (ashore,  deployed,  maint.  availability,  etc.) _ _ 

2.  The  new  National  Imagery  and  Mapping  Agency  (NIMA)  is  currently  working  on  providing  digitized  charts  and 
publications  to  the  fleet  user.  Are  there  any  requirements  that  you  have  which  you  would  like  to  be  included  in 
NlMA’s  efforts? 


3.  Would  you  prefer  to  keep  the  current  publication  system  for  navigation  planning,  or  would  you  prefer 
to  have  a  new  interactive  “on-line”  system  developed? 


4.  What  type  of  Navigation  Lessons  Learned  “library”  (if  any)  does  your  command  maintain  now? 


5.  What  configuration  would  you  prefer  for  a  consolidated  location  or  “library”  of  electronic  Navigation  information? 


Note:  For  question  (6),  please  choose  the  degree  of  importance  of  each  type  of  data  from  one  of  the  following: 

1 .  Not  Important  2.  Somewhat  Important  3.  No  Opinion/Neutral  4.  Important  5,  Essential 

6.  If  the  following  navigation  related  information  sources  were  accessible  in  a  single  location,  how  important  would 
they  be  to  you?  (Please  circle  your  choices! 

1  2  3  4  5  Pictures  of  aids  to  navigation  (range  markers,  towers,  tanks,  lights,  etc.) 

1  2  3  4  5  Lessons  Learned  from  other  commands  vAio  have  “gone  before” 

1  2  3  4  5  Digitized  navigation  publications  (Sailing  Directions,  Coast  Pilot, 

List  of  Lights/Light  List,  Fleet  Guides,  etc.) 

1  2  3  4  5  Digitized  charts  and  display 
1  2  3  4  5  Safety  messages  (HYDROPAC/LANT,  NOTAMS) 

1  2  3  4  5  Overhead  littoral  imagery  of  navigation  value 
1  2  3  4  5  Amphibious  planning  data  (hydro  surveys,  assault  plans,  etc.) 

1  2  3  4  5  Historical  exercise  data  (conops,  clearance  requirements,  lead  times,  etc.) 

1  2  3  4  5  Meteorological  data  (tide/current  predictions,  prevailing  conditions,  etc.) 

1  2  3  4  5  Port  data  (pilotage,  tugs,  berth  and  port  facilities,  etc.) 


7.  What  navigation  data  or  information  sources  would  you  add  to  a  single,  central  navigation  “library?” 
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8.  I  have  used  the  Navy  Tactical  Information  Compendium  (NTTC)  series  library  and  Navy  Lessons  Learned  System 
as  follows  (please  check  all  choices  which  apply): 

Purpose 
0  Exercise 
0  Transit 
0  Port  Visit 
0  Amphib  Ops 
0  Other _ 


9.  On  average,  my  command  spends  the  following  amount  of  time  (in  manhours)  every  week  maintaining  and 
correcting: 

Itern  Time  spent  maintaining 

0  HYDROPAC/LANT  and  Notam  files  _ 

0  Navigation  Publications  _ 

0  Charts  _ 

9  Other _ 


10.  In  previous  planning,  what  missing  information  did  you  need  from  other  commands  who  had  completed  the 
same  event? 


Frequency  of  Use 
0  Never 

0  Seldom  (i.e.  once/mo.  or  less) 

0  Regularly  (i.e.  once/wk.  or  more) 
0  Other _ 


1 1 .  I  have  used  the  following  systems  for  navigation  planning  (check  all  that  apply): 

0  GCCS  0  WWW  •  0  JDISS  0  Commercial  Software  0  Other _ 

Title: _ 

12.  If  you  have  used  a  system  from  question  (1 1)  for  navigation  planning,  for  what  purpose  did  you  use  it? 


13.  In  order  to  improve  fleet  feedback  and  to  capture  Navigation  Lessons  Learned,  an  improved  method  needs  to  be 
developed.  Quantitative  data  (i.e.  rating  of  tugs  and  pilot,  navigation  aid  usefulness,  etc.)  as  well  as  qualitative 
comments  need  to  be  collected.  Please  provide  your  thoughts  on  how  this  could  best  be  accomplished. 


14.  We  are  looking  for  ideas  to  improve  fleet  navigation  planning,  and  we  welcome  your  feedback.  Please  provide 
any  comments  or  suggestions  in  the  space  below,  and  feel  free  to  attach  additional  sheets  if  necessary.  Thank  you  for 
your  cooperation. 
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APPENDIX  C.  SURVEY  DEMOGRAPHICS 


The  following  tables  provide  statistics  on  the  number  of  respondents  and  their 
demographic  makeup. 


General 

Surveys  Population 

Percentage 

Information 

Received 

Size 

of  Pop. 

Number  of  Total  Respondents: 

238 

Number  of  Total  Commands: 

159 

396 

40.2% 

Number  of  Ships: 

130 

333 

39.0% 

Number  of  Staffs: 

29 

63 

46.0% 

Lost  Surveys 

1 

MiscAJnresolved 

1 

Ships  by  Type;  CV/CVN 

6 

12 

50.0% 

CG/CGN 

12 

27 

44.4% 

DD/DDG 

21 

56 

37.5% 

FFG 

16 

42 

38.1% 

Total  CRUDES 

49 

125 

39.2% 

SSN 

24 

68 

35.3% 

SSBN 

6 

18 

33.3% 

Total  Subs 

30 

86 

34.9% 

LCC 

1 

2 

50.0% 

LHA 

3 

5 

60.0% 

LHD 

0 

5 

0.0% 

LPD 

2 

11 

18.2% 

LPH 

1 

1 

100.0% 

LSD 

5  . 

16 

31.3% 

LST 

1 

2 

50.0% 

Total  Amphibs 

13 

42 

31.0% 

MCS 

0 

1 

0.0% 

MCM 

8 

14 

57.1% 

MHC 

2 

9 

22.2% 

Total  Mine 

10 

24 

41.7% 

Warfare 
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PC 

5 

13 

38.5% 

AE 

2 

2 

100.0% 

AO 

2 

5 

40.0% 

T-AFS/AO/ATF 

4 

4 

100.0% 

AOE 

3 

7 

42.9% 

Total  Logistics 

11 

18 

61.1% 

AS 

3 

4 

75.0% 

AGF 

1 

2 

50.0% 

AGSS 

1 

1 

100.0% 

ARS 

2 

4 

50.0% 

Total  Aux  Ships 

7 

11 

63.6% 

Total 

131 

331 

39.6% 

Staffs  By  Type 

Fleet 

2 

5 

40.0% 

CARGRU 

4 

8 

50.0% 

CRUDESGRU 

2 

6 

33.3% 

DESRON 

7 

17 

41.2% 

SUBGRU 

5 

5 

100.0% 

SUBRON 

3 

10 

30.0% 

PHIBRGRU 

0 

3 

0.0% 

PHIBRON 

4 

9 

44.4% 

Total 

27 

63 

42.9% 

Months  in  Job 

Percent 

Rank 

>36 

26  10.9% 

>E-7 

37 

12  to  36 

103  43.3% 

<=E-6 

44 

<  12 

97  40.8% 

Second 

Officer 

3 

Not  Specified 

12  5.0% 

0-1  -  0-3 

113 

Total 

238 

0-4 

28 

05-0-6 

10 

Job  Title 

Unknown 

3 

Navigators 

103 

Total 

238 

Asst.  Navig. 

30  (Duplicates  w/  Nav  LCPOs) 

Staff  Nav 

6 

CO 

2 

cso 

4 

xo 

13 

Operations  Officer 

31 
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OPS  Jobs 
NAVLPO/LCPO 
OPS  LPO/LCPO 

QMS _ 

Total 


14  (Asst.Ops,  CICO,  Amphib  Ops,  StaflFOps,  Schedulers) 
20 
14 
7 

244 


Respondents  by  Job 


^  Navigators 

■  Asst.  Navig. 
^  Staff  Nav 

■  CO 
0CSO 


■  Operations  Officer 

■  OPS  Jobs 

■  NAVLPO/LCPO 
□  OPS  LPO/LCPO 

■  QMS 
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APPENDIX  D.  STATISTICAL  CALCULATIONS  FOR  POPULATION  MEAN 

CONFIDENCE  INTERVALS 


The  following  calculations  show  values  used  to  compute  the  confidence  intervals 
depending  on  sample  and  population  size.  With  only  13  respondents,  the  student’s  “t” 
distribution  was  required  for  Amphibious  results.  The  number  of  navigators  responding 
was  large  enough  to  use  standard  normal  distribution  computations. 

The  symbols  used  in  the  tables  are: 

N=  Observations 

0  =  Sample  mean 

O  =  Population  mean 

Sx  =  Sample  standard  deviation 

Z  alpha/2  =  Standard  normal  random  variable 

tn-i  =  Random  Variable  from  Student’s  t  distribution  with  (n-1)  degrees  of  freedom 

Formula  for  calculating  the  Confidence  interval  for  the  Mean  of  a  Normal  Population, 
small  sample  size 


0 - (t„.i).  Sx/  SQRT(N)  <  d)<  0  + 

(tn-i).  Sx/  SQRT(N) 

N 

Amphibious 

13 

13 

13 

0 

4.29 

4.29 

4.29 

Sx 

0.85 

0.85 

0.85 

tn-l 

95% 

90% 

80% 

Table  value 

2.179 

1.782 

1.356 

Pop  Mean  Range 

Low  value 

3.78 

3.87 

3.97 

High  value 

4.80 

4.71 

4.61 
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Confidence  Interval  for  the  Population  Mean:  Large  Sample  Sizes 

Note:  When  the  sample  size  is  large,  the  sample  standard  deviation  will  be  a  sufficiently 
good  estimator  of  the  population  standard  deviation  to  allow  us  to  use  the  former  in  place 
of  the  latter  without  affecting  the  probability  content  of  the  intervals. 

0 - (Z alpha/2)*S*/  SQRT(N)  < d)< 0  +  (Z alpha/2)*Sx/  SQRT(N) 


Navigators 


N 

103 

103 

103 

0 

4.19 

4.19 

4.19 

Sx 

0.71  . 

0.71 

0.71 

Z  alpha/2 

99% 

95% 

90% 

Table  Value 

2.57 

1.96 

1.65 

Low  Value 

4.01 

4.05 

4.07 

High  Value 

4.37 

4.33 

4.31 

All 


N 

Responses 

238 

238 

238 

XBar 

4.1 

4.1 

4.1 

Sx 

0.94 

0.94 

0.94 

Z  alpha/2 

99% 

95% 

90% 

Table  Value 

2.57 

1.96 

1.65 

Low  Value 

3.94 

3.98 

4.00 

High  Value 

4.26 

4.22 

4.20 
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APPENDIX  E.  NAVIGATION  SURVEY  RESULTS 


These  are  narrative  responses  to  survey  questions  2,  3,  5, 1,  10,  and  14,  received  from 
July  to  October,  1997.  Not  all  responses  from  all  commands  who  participated  in  the 
survey  are  included  here.  Comments  from  commands  who  provided  thorough  responses 
which  are  useful  to  navigation  planning  are  listed.  Responses  are  paraphrased,  and  in 
some  cases  are  directly  quoted  as  indicated. 


USS  SALVOR  (ARS-52),  Navigator 

•  Need  a  Waypoint  to  Waypoint  (voyage  planning)  calculator. 

•  Good  argument  for  “single  source”  Nav  Repository  in  response  #3 

•  Include  “Typhoon  Havens” 

USS  PRINCETON  (CG-59),  Navigator 

•  Strong  argument.for  Pictures  of  Navaids ! 

•  Good  argument  for  CD-Rom  technology  (updatable?) 

•  Make  digital  charts  vector  charts  (vice  Raster)  which  are  easily  updated  with 
commercial  software. 

FFG,  Navigator 

•  “Put  AAR  File  from  DC  into  a  database.”  (FICM  Port  Visit  Report) 

USS  SIMPSON  (FFG-56),  Ops 

•  “Make  SURFLANT  port-visit  reports  (FICM  Format)  available  in  a  database!” 

•  Include  access  to  NGFS,  Bottom  Contour  and  Jog-Air  Charts 

COMCARGRU  TWO,  Surface  Ops  Officer 

•  Query  port  database  by:  1)  name,  2)  lat/lon 

•  Port-to-Port  transit  and  time/distance  figures 

USS  TAYLOR  (FFG-50),  XO 

•  “Investigate  commercial  nav  software  the  Coast  Guard  uses.” 

•  Include  Traffic  Patterns 

•  Condition  of  piers  and  camel/fender  capability 

•  Foreign  Port  Tides 

COMSUBGRU  TWENTY,  Asst.  Ops  Officer 

•  Include  classified  NOTAMs 

•  Changes  in  Shoaling 

DESRON  TWO,  Navigator 


97 


•  Distances  between  ports 

•  Terrestrial  (road/area)  Maps  of  Arabian  Gulf  Ports  to  help  determine  usable 
Navaids 

•  Pictures  of  Harbor 

USS  KITTY  HAWK  (CV-63),  Chief  Quartermaster 

•  “It  would  be  great  for  all  afloat  units  to  have  access  to  WWW  to  be  able  to 
access  NAV  info  any  time.” 

•  “GPS  Interfaceable” 

•  Accepts  NIMA’s  digital  charts” 

•  “Depths  at  berths” 

USS  DEXTROUS  (MCM-13),  XO/Navigator 

•  Beach  Topography 

•  Bottom  contours/type/gradient 

•  Display  ship  size  to  scale 

•  “On-line  would  save  space  on  cramped  MCM” 

USS  ENTERPRISE  (CVN-65),  Navigator 

•  ECDIS  Planning  Tool? 

•  Accurate  Port/ Anchorage  charts  for  frequently  visited  foreign  ports. 

USS  L.  MENDEL  RIVERS  (SSN-686),  Nav/Ops 

•  “Include  foreign  charts”  (especially  for  ports) 

USS  TORTUGA  (LSD-46),  Navigator 

•  Standard  Approach  Tracks 

•  Lights  and  Navaids  with  Pictures  and  Descriptions 

•  Plot  tracks,  anchorages,  boat  lanes 

•  Ability  to  calculate  celestial  data... movreps... trip  planning 

•  Coverage  of  “Hard  to  Reach”  Areas 

USS  CROMMELIN  (FFG-37),  Navigator 

•  Include  OP  AREAS  (as  overlays) 

•  Pier  data,  tug  availability,  BTB  channel 

•  Recommended  pilot  pick-up  points 

USS  O’BRIEN  (DDG-975),  Leading  QM 

•  Need  Nav  Dept.  Hardware  support!  (PC,  CD-ROM,  modem,  dedicated  phone 
line,  etc.) 
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USS  PONCE  (LPD-15),  Navigator 

•  “Bulletin  Board”  for  on-line  system 

LHA  (Westcoast),  Navigator 

•  Include  “British  Recommended  Route  Book” 

USS  COLUMBUS  (SSN-762),  Navigator 

•  Visual  LOPs  into  auto-updated  position 

•  Ability  to  “personalize”  graphical  display. . .  .Navaids  highlighted,  Tug  RD VU 
points,  etc. 

USS  COMSTOCK  (LSD-45),  Navigator 

•  Develop  a  Cross-Reference  System  to  enable  ordering  Foreign  Charts 

•  “Make  it  like  JICPAC  Home  Page” 

USS  SOUTH  CAROLINA,  Navigator 

•  Use  MOVREP  for  PVISIT  Feedback 

•  Disk/CD  updates  for  non-Internet  Commands 

USS  SACRAMENTO  (AOE-1),  Asst.  Navigator 

•  NAVTREK 

•  Digital  Chart  Display  with  GPS  Interface 

•  (DBMS)  Query  by  Port 

USS  KLAKRING  (FFG-42),  Navigator 

•  Include  “Safe  Speed”  along  port  transit  legs 

•  Pilot  Pickup  Points 

CRUDESGRU  TWO,  Navigator 

•  Include  Pictures  of  Navaids! 

•  “Hot”  Areas 

SUBRON  ONE,  Ops  Officer 

•  3-D  Charts  for  subs! 

COMCARGRU  FIVE,  Sub  Ops 

•  Vector  Charts  vice  Raster 

•  E-Series  Sub  Charts  digitized  by  NEMA 

•  GPS-ESGN 

•  LAN  accessible  display 

•  Select/Deselectable  information;  design  Web  Site  with  “filtering!” 
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USS  CHIEF  (MCM-14),  Navigation  Officer 

•  MCM’s:  not  enough  phone  lines  for  NAVINFONET  dump! 

•  Add  to  PCO/PXO  pipeline  training  on  electronic  NAV  technology. 

COMDESRON  FIVE,  Navigator 

•  WRN-6  Interface 

•  Pierside  Depths 

•  Feedback  form  for  ideas 

•  Training/Documentation  for  new  system 

USS  GUNGSTON  HALL  (LSD-44),  Navigator  and  Ops  Officer 

•  Forego  Celestial  Navi  (Nav) 

•  Include  Husbanding  Agent  e-mail  address  (Ops) 

CLF  (AO),  Navigator 

•  Consolidate  Nav  transit/port  visit  feedback  with  MOVREP. 

USS  MIAMI  (SSN-755),  Navigator 

•  Include  bottom  contour  charts 

•  Traffic  Density  for  Port  Visits 

USS  CLARK  (FFG-1 1),  LPO  Nav.  Dept. 

•  “Storm  Tracking”  function 

USS  SENTRY  (MCM-3),  ANAV  (QMl(SW)  Powell) 

•  Great  tool;  Integrating  GPS  and  Cap’n  onboard. 

USS  AUSTIN  (LPD-4),  ANAV 

•  QMC  memo  to  CNSL  has  documented  need  to  upgrade  Nav  planning 
technology 

USS  LOUISVILLE  (SSN-724),  Navigator 

•  Produce  “Chartlets”  of  OPAREAS  (Cargru  7) 

•  “JMCIS  compatible” 

CVN,  ANAV 

•  Downloaded  off  ofNIPRNET/SIPRNET 

•  Include  Port  visit  reports 

•  Include  Pictures  of  Navaids 

USS  INDEPENDENCE  (CV-62),  LCPO 

•  Include  on  Web  site;  “Advance/Transfer  tables  for  ship  class” 
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USS  ARKANSAS  (CGN-41),  Navigator 

•  Highlightable  shoal  water  based  on  ship’s  draft/input 

•  Display  current  vectors  real-time  (direction  and  velocity) 

•  Database  of  historical  OTSR  divert  data 

•  Generate  Nav  Aids  expected  to  see  based  on  intended  track 

•  Civilian/NOAA  POC  for  improving  NAV 

USS  MONTPELffiR  (SSN-765),  CO 

•  Internet  unavailable  while  submerged! 

•  Digital  charts  and  pubs  would  greatly  ease  sub  stowage  problem! 

AE,  Navigator  (West  Coast) 

•  Add  Harbor  “Common  Approach”  tracks 

CARGRUFOUR,  Staff  QM 

•  Point  and  Click  to  get  blown  up  Picture  of  Navaid! 

•  Digitized  charts/pubs  would  bring  postage/shipping  savings  as  a  tangible 
benefit 

COMDESRON  FIFTEEN,  OSC 

•  “Software  to  simplify  ordering  charts”  (push/pull  technology) 

•  Time-Distance  planning 

•  “Fuel  Bum  Predictions”  by  ship  class 

USS  PHILIPPINE  SEA  (CG-58),  Navigator 

•  Query  (i.e.,  NavAreas,  Hydrolants  by  Chart  #) 

•  Pilot  pick-up  pts,  anchorages 

•  Make  feedback  form  a  TYCOM  directive 

USS  STOUT  (DDG-55),  Navigator 

•  SURFLANT  Database  (ports)  available  upon  request  via  Code:  CNSL  N333 

USS  PETERSON  (DD-969),  Navigator 

•  Want  “Pier”  info:  Depth  at  berth,  pier  specs,  etc. ! 

COMDESRON  TWENTY  SIX,  Chief  of  Staff 

•  “Danger  Contours” 

•  Bearings  based  on  ship  class 

•  Status  of  lights/navaids:  “Operational,  light  out...” 
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PC,  CO 

•  Need  system  compatible  with  PC  CZATVIS  system 

USS  AUBREY  FITCH  (FFG-34),  LPO 

•  Be  able  to  change  scale  of  chart  (zoom  in/out) 

•  (MIMA  Feedback)  Need  better  scale  charts  for  Panama  Canal,  etc. 

USS  ROBERT  G.  BRADLEY  (FFG-49),  Navigator 

•  “Standardize  the  names  of  Navaids,  so  that  all  USN  ships  called  the  available 
Navaids  by  the  same  name.” 

•  “Found  that  many  of  the  Navaids  we  thought  would  work  didn’t.” 

USS  TREPANG  (SSN-674),  Ops. 

•  Put  Navaid  ID  on  charts  so  periscope  operator  can  quickly  and  correctly 
identify  Navaids. 

USS  JAMES  K.  POLK  (SSN-645),  Navigator 

•  See  SUBPAC/LANT  Inst.  5400  (Nav  Operations  Dept.) 

•  CINCLANTFLEET  and  CINCUSNAVEUR  maintain  vast  list  of  port  visit 
reports 

•  Include  DOD  2005.  IM  Maritime  Claims  Manual  for  pub  digitization. 

USS  CIMARRON  (AO- 177),  Navigator 

•  Digital  Chart  system  should  have  onboard)  “printing  capability  for  portable  use 
like  for  Boat  Officers.” 

USS  FIFE  (DD-991),  CO 

•  Revive  old  USN  “Mishaps  at  Sea”  database/pub. 

USS  HUE  CITY  (CG-66),  Navigator 

•  Anchorage  Positions  and  bearings  (visual  aids). 

USS  ZEPHYR  (PC-8),  Ops. 

•  “We  digitize  our  own  charts” 

•  Compatible  with  Sperry  IBS  System? 

USS  TICONDEROGA  (CG-47),  XO/Nav. 

•  Need  to  verify  accuracy  (and  quality)  of  nav  data  in  repository. 

•  Data  vulnerability  concern. 

USS  CALIFORNIA  (CGN-36),  Navigator 

•  Pictures  of  Ports,  Piers,  Passages,  and  Straits 
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Description  of  Pier  configuration 


COMDESRON  SIX,  Ops/Plans 

•  “One-Stop-Shopping” 

•  Pictures  of  Navaids 

•  “Huge  LAN  w/ CD  Jukebox” 

USNS  SAN  JOSE  (T-AFS-7),  Navigator 

•  “Design  (system/repository)  so  that  merchants  can  voluntarily  contribute 
feedback.” 

USS  NICHOLAS  (FFG-47),  Asst.  Navigator 

•  Include  Suez  Canal  Transit  info. 

USS  PAUL  HAMILTON  (DDG-60),  CO 

•  Pier  depths 

•  Pilot  proficiency  info.,  ex.,  years  experience 

•  DDG:  “Digital  pubs  save  space” 

•  “Put  pictures  of  navaids  on  the  Web” 

SUBMARINE  SQUADRON  TWO,  Deputy  Commander 

•  “Need  adequate  survey  data  for  safe  submerged  operations  in  littoral  shallow 
waters.” 

•  “More  local  knowledge  about  direction  and  magnitude  of  current  at  various 
places  along  track.” 

DESTROYER  SQUADRON  SEVEN,  CICO 

•  “Include  standard  4W  grids  in  Opareas  to  alleviate  confusion.” 

•  “DGPS. .  .is  of  sufficient  accuracy/quality  to  be  used  for  harbor  transits  instead 
of  visual  fixes.” 

•  Include  Code  of  Federal  Regs  (CFR)  Panama  Canal  Transit  information. 

<also;  St.  Lawrence  Seaway  and  Locks,  Kiel  Canal/Locks,  Suez  Canal,  etc.> 

•  Commands  need  to  debrief  Sea  &  Anchor  details  and  capture  the  lessons 
learned. 

USS  GUAM  (LPH-9),  Asst.  Navigator 

•  “USN  should  embrace  the  CAP’N  program... current  Instructions  require  us  to 
operate  in  the  Dark  Ages!” 

USS  FITZGERALD  (DDG-62),  CICO 

•  Using  Raytheon  ECDISS 
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Have  NIMA  conduct  an  annual  NAVIGATION  PLANNING  Symposium  to 
brief  improvements  in  services  and  products. 


USS  JACKSONVILLE  (SSN-699),  Asst.  Navigator 

•  Pictures  of  Navaids 

SUBMARINE  GROUP  TWO,  Ops.  Officer 

•  Navigation  Planning  is  far  behind  current  technology! 

USS  SANTA  FE  (SSN-763),  Nav/Ops 

•  “(Nav  Info)  System  would  need  to  be  integrateable  into  SNAP-III  LAN” 

•  Need  up-to-date  location  info  on  Arabian  Gulf  and  WESTPAC  Oil  Rig 
locations. 

•  Location  info.  On  special  purpose  Buoys  such  as  Hawaiian  “Fish  Aggregating 
Device”  (FAD)  Buoys. 

USS  PELELIU  (LHA-5),  Navigator/ Asst.  Navigator 

•  “Centrally  locating  multiple  sources  of  Nav.  Info,  by  a  geographical  database 
would  be  a  great  help!” 

•  Look  at  CJCS  Instruction  6130.01  dtd  20May94  “CJCS  Master  Navigation 
Plan” 

•  Do  away  with  traditional  visual  fixing;  use  GPS  exclusive  fixing! 

USS  POGY  (SSN-647),  Ops.  /Nav. 

•  Traffic  Density  and  Patterns 

DESTROYER  SQUADRON  TWO,  Chief  of  Staff 

•  Use  TOPSCENE  for  Nav  Planning 

USS  FRANK  CABLE  (AS-40),  Nav/Ops 

•  Include  Traffic  Density  data. 

USS  OHIO  (SSBN-726),  Navigator 

•  Include  “Downloadable”  Power  Point  Nav.  Briefs. 

AMPHIBIOUS  SQUADRON  SIX,  Ops. 

•  Collect  repository  of  (landing)  beach  hydrographic  surveys. 

•  Mobile  staffs  would  greatly  benefit  from  digitized  pubs  and  charts  (Note;  same 
reported  by  MCM’s,  SSN’s,  DDGs  and  FFGs)! 

SIXTH  FLEET,  Asst.  Fleet  Scheduler 

•  Collect  cost  data  with  Port  Visit  Report  per  C6F  prototype  tool. 
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USS  YORKTOWN  (CG-48),  CICO/Nav. 

•  “SMART  SHIP”  Plan;  Only  maintain  one  set  of  charts. 

USS  THE  SULLIVANS  (DDG-68),  QM 

•  More  pictures  of  Navaids  (a  picture  is  worth  a  thousand  words). 

•  Pictures  that  show  what  the  harbor  looks  like  (NOAA  Charts,  do  this  with  a 
few  of  those). 

•  Digital  Charts  -  “new  Coast  Guard  Buoy  Tenders  in  Newport  showed  me  the 
Digital  Chart  System  that  fed  into  the  control  stations  -  it  was  great!” 

•  Common  pilot  practices  in  different  ports. 

USS  BELLEAU  WOOD  (LHA-3),  Navigator 

•  Pictures  of  Harbor  Approaches 

USS  PATRIOT  (MCM-7),  QM 

•  Recommended  Port  approaches 

•  Digital  Nav  Pubs,  i.e.,  sailing  directions  and  Pub  151 

•  “Put  all  Nav  info,  on  a  single.  Worldwide  network” 

•  Include  EEZ,  political  boundaries,  buffer  zones,  etc.  on  digital  charts. 

USS  THORN  (DD-988),  Ops./Nav. 

•  Scalable,  editable  (digital)  charts  where  operator  can  superimpose  tracks, 

OP  AREAS,  etc. 

USS  JOHN  F  KENNEDY  (CV-67),  Navigator 

•  “Raytheon  ECDIS  disks  were  corrupted” 

•  Repository  of  feedback  accessible  through  WWW 

•  All  pubs  accessible  through  WWW 

USS  FLETCHER  (DD-992),  Navigator 

•  Store  PowerPoint  Nav  Briefs 

•  Need  a  “One-Stop  Library” 

•  “Scaling  feature”  for  digital  charts 

AMPHIBIOUS  SQUADRON  11,  CSO 

•  Repository  of  Beach  Surveys 

•  Beach  Imagery 

USS  THACH  (FFG-43),  Navigator 

•  Include  merchant  vessel  feedback  and  lessons  learned  re;  navigation. 
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SUBMARINE  GROUP  7,  ACOS/Ops. 

•  Make  digital  chart(s)  “edgeless”  so  that  you  auto-shift  to  new  chart. 

USS  MOUNT  HOOD  (AE-29),  Navigator 

•  Include  all  (different)  spellings  for  foreign  ports. 

AMPHIBIOUS  SQUADRON  FIVE,  SAC 

•  E-mail  feedback  to  a  database. 

USS  GEORGE  WASHINGTON  (CVN-73),  Navigator 

•  Have  NIMA  digitize  OP  AREA  Charts  and  distribute  via  ECDIS 

•  Add  to  Nav  library:  Airfields  (Bingo  fields),  Sub  transit  lanes,  traffic  separation 
schemes,  oil  rig  locations. 
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APPENDIX  F.  SURVEY  QUESTION  6  GRAPHS 
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Graph  F- 1 


Pictures  Les  Learned  Dig  Pubs  Dig  Charts  Safety  Imagery  Amphib  Exercise 
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Response  Distribution-  One  Survey  per  Command 


Response  Distribution  by  Percent-  Aii  Respondents 


■c 

o 

£L 


& 

0) 


0) 

in 


u 


I 

CO 


I 


CO 

JZ 


O 


O) 

b 


(0 

2 

Q. 


109 


Graph  F-  3 


Graph  F-  4 
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Ill 


Graph  F-  5 


Pictures  L-Learned  Dig  Pubs  Dig  Charts  Safety  Imagery  Amphib  Exer.  Data  Metro  Port  Data 
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Ship  V  Sub  V  Staff 
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Graph  F-  7 


Pictures  L-Learned  Dig  Pubs  Dig  Charts  Safety  Imagery  Amphib  Exer.  Data  Metro  Port  Data 
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Big  Deck  v  Small  Boy  Graph 
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Graph  F-  9 


Pictures  L-Learned  Dig  Pubs  Dig  Charts  Safety  Imagery  Amphib  Exer.  Data  Metro  Port  Data 
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Time  in  Billet  (Months) 


Results  by  Rank 
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Graph  F-  11 


APPENDIX  F.  GRAPH  DATA 
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Time  in  Digitized  Digitized  Xercise  Port 

Billet  Pictures  L-Leamed  Pubs  Charts  Safety  Imagery  Amphib  Data  Metro  Data 
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Time  in  Digitized  Digitized  Xercise  Port 
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